Question

I have a solution in VS2010 with several projects, each making up a layer within my application. I have business entities which are currently objects with no methods, and I have a management layer which references the business entities layer in it’s project. I now think I have designed my application poorly and would like to move methods from helper classes (which are in another layer) into methods I’ll create within the business entities themselves.

For example I have a VirtualMachine object, which uses a helper class to call a Reboot() method on it which passes the request to the management layer. The static manager class talks to an API that reboots the VM. I want to move the Reboot() method into the VirtualMachine object, but I will need to reference the management layer:

public void Reboot()
{  
    VMManager.Reboot(this.Name);
}

So if I add a reference to my management project in my entities project, I get the circular dependency error, which is how it should be. How can I sort this situation out? Do I need to an yet another layer between the entity layer and the management layer? Or, should I just forget it and leave it as it is.

The application works ok now, but I am concerned my design isn’t particularly OOP centric and I would like to correct this.

Answer 1

You are correct, you should not make circular references, making another layer might just help you avoid the circular reference error, but it will still be a circular reference, if i understood you correctly.

I would sit down, draw a map and methods should ONLY call down in layers. That is the most general methods at the “bottom” of the program, and the more specialized you get the higher up in the hierarchy you should put it.

The API of the program you are making should be on the bottom of this hierarchy.

You might not need to redesign your whole project. But it sounds like you could help yourself with visualizing the structure.