views:

83

answers:

2

I want to use dependency injection (Unity) and at the moment I'm thinking about how to setup my project (it's a fancy demo I'm working on).

So, to fully decouple all components and have no more assembly dependencies, is it advisable to create an assembly ".Contracts" or something similar and put all interfaces and shared data structures there?

Would you consider this the best practice or am I on a wrong track here?

What I want to accomplish:

Full testability, I want all components as sharply decouples as possible and inject everything, no component will ever talk directly to a concrete implementation anymore.

+3  A: 

The first and probably most important step is to program to interfaces, rather than concrete implementations.

Doing so, the application will be loosely coupled whether or not DI is used.

Finglas
yes, but would you place all the interfaces together in a single assembly / library / project?
StormianRootSolver
It depends. If the components are definetly used in other projects, yes. If not, within the same project, yet a sensible structure is fine.
Finglas
Thank you. I have made my decision now. I will follow your suggestion and create a .Contracts project where I put all the interfaces which are used by multiple assemblies. :-)
StormianRootSolver
+1  A: 

I wouldn't separate interfaces in other assembly. If you have to interact with something that is a part of your domain, why separate it? Examples of interfaces are repositories, an email sender, etc. Supose you have a Model assembly where you have your domain objects. This assembly exposes the interfaces, and implementations, obviously, reference Model in order to implement them.

bloparod
+1 for your answer! :-) But how would you go about classes depending on total strangers to work? I mean, imagine you have a service component that depends on the same configuration file accessor class as, say, a printing system? Wouldn't one introduce too many references in this case?
StormianRootSolver