First, I want to say that I am not interested in debating about any non-helpful "answers" to my question, with suggestions to putting everything in one assembly, i.e. there is no need for anyone to provide webpages such as the page titled with "Separate Assemblies != Loose Coupling".
Now, my question is if it somehow (maybe with some Visual Studio configuration to allow for circular project dependencies?) is possible to use one project/assembly (I am here calling it the "ServiceLocator" assembly) for retrieving concrete implementation classes,
(e.g. with StructureMap) which can be referred to from other projects, while it of course is also necessary for the the ServiceLocator itself to refer to other projects with the interfaces and the implementations ?
Visual Studio project example, illustrating the kind of dependency structure I am talking about:
http://img10.imageshack.us/img10/8838/testingdependencyinject.png
Please note in the above picture, the problem is how to let the classes in "ApplicationLayerServiceImplementations" retrieve and instantiate classes that implement the interfaces in "DomainLayerServiceInterfaces".
The goal is here to not refer directly to the classes in "DomainLayerServiceImplementations", but rather to try using the project "ServiceLocator" to retrieve such classes, but then the circular dependency problem occurrs...
For example, a "UserInterfaceLayer" project/assembly might contain this kind of code:
ContainerBootstrapper.BootstrapStructureMap(); // located in "ServiceLocator" project/assembly
MyDomainLayerInterface myDomainLayerInterface = ObjectFactory.GetInstance<MyDomainLayerInterface>(); // refering to project/assembly "DomainLayerServiceInterfaces"
myDomainLayerInterface.MyDomainLayerMethod();
MyApplicationLayerInterface myApplicationLayerInterface = ObjectFactory.GetInstance<MyApplicationLayerInterface>(); // refering to project/assembly "ApplicationLayerServiceInterfaces"
myApplicationLayerInterface.MyApplicationLayerMethod();
The above code do not refer to the implementation projects/assemblies ApplicationLayerServiceImplementations and DomainLayerServiceImplementations, which contain this kind of code:
public class MyApplicationLayerImplementation : MyApplicationLayerInterface
and
public class MyDomainLayerImplementation : MyDomainLayerInterface
The "ServiceLocator" project/assembly might contain this code:
using ApplicationLayerServiceImplementations;
using ApplicationLayerServiceInterfaces;
using DomainLayerServiceImplementations;
using DomainLayerServiceInterfaces;
using StructureMap;
namespace ServiceLocator
{
public static class ContainerBootstrapper
{
public static void BootstrapStructureMap()
{
ObjectFactory.Initialize(x =>
{
// The two interfaces and the two implementations below are located in four different Visual Studio projects
x.ForRequestedType<MyDomainLayerInterface>().TheDefaultIsConcreteType<MyDomainLayerImplementation>();
x.ForRequestedType<MyApplicationLayerInterface>().TheDefaultIsConcreteType<MyApplicationLayerImplementation>();
});
}
}
}
So far, no problem, but the problem occurs when I want to let the class "MyApplicationLayerImplementation" in the project/assembly "ApplicationLayerServiceImplementations" use the "ServiceLocator" project/assembly for retrieving an implementation of "MyDomainLayerInterface".
When I try to do that, i.e. add a reference from "MyApplicationLayerImplementation" to "ServiceLocator", then Visual Studio complains about circular dependencies between projects.
Is there any nice solution to this problem, which does not imply using refactoring-unfriendly string based xml-configuration which breaks whenever an interface or class or its namespace is renamed ?
/ Sven
