Using StructureMap, is one of these project organizations better than another?

Question

I'm starting to work with StructureMap on a windows application project. In working on learning the basics, I found 2 ways to arrange my solution that accomplish the same goal, and I'm wondering if anyone can comment on if one of these 2 seems like a better option, and why.

The goal here was to use IOC so that I could use 2 services without taking dependencies on them. So I I created interfaces in my Business Layer, and then implemented those interfaces in my Infrastructure project and wrapped the actual services at that point.

In my fist attempt at this, I created a project DependencyResolver, which has code to intialize structuremap using the fluent interface (when someone wants IServiceA, give them an instance of ServiceX). Because the initialization of DependencyResolver needed to be kicked off from my app, I have a reference from the app to DependencyResolver like this:

So then I found that I could remove my reference to DependencyResolver, and rely on StructureMap scanner and naming conventions to get that reference at runtime, so then my setup looks like this:

So then, I took the naming conventions further, down into the services I was using, and was able to do away with the DependencyResolver all together. At this point, I am totally relying on the structuremap scanner and naming conventions to get things setup correctly:

So. Here I am, not quite sure how I should feel about these 3 options. Option 1 seems good, except I'm left with the UI indirectly referencing all the things that it shouldn't be referencing (directly) because of the use of StructureMap. However, I'm not sure if this really matters.

Option 2 removes the need for a reference from the app to DependencyResolver, and relies on naming conventions to access classes in that project, and I still have a high level of control over all the remaining setup (but I have now taken a dependence on structureMap directly from my application).

Option 3 seems the easiest (just name everything a certain way, and scan your assemblies), but that also seems more error prone, and brittle. Especially if I wanted to do something a little more complex than IServiceAbc => ServiceAbc.

So, can anyone who has a lot more experience with this stuff that I do give me some advice?
Should I be avoiding the indirect references from my App to my services, and if so, what are the real benefits of doing that? Am I right that trying to do everything with naming conventions is only wise on simple projects?
Is there a standard pattern for doing what I'm trying to do here?

Sorry for the long post..

Dannie

Answer 1

Encapsulate all usage of StructureMap in a Composition Root and use Constructor Injection throughout the rest of your code base.

You can implement the Composition Root in a separate assembly if you'd like, but I usually prefer placing it directly in the executable itself, and then implement all of the application logic in separate libraries.

Cassondra

If I put it in the application itself, then my app would have to directly reference all the assemblies in the project ( even if all the code used to access those assemblies was done via an interface ) for the purpose of setting up the container. Doesn't that seem less than ideal? Maybe it doesn't really matter, but it seems better organized to have the app and domain/business layer not have any references to the 3rd party services . – Dannie

That's why you want to put the domain model in a separate assembly. – Cassondra

This architecture separation needs more elaboration – December

Answer 2

I have used the top design on projects and it work extremely well.

Dependency resolvers are more or less factories to return interface instances, isn't structure map just one way to implement this? In that case I would make request for any item via the dependency resolver at one central place. Then it is also possible to remove structure map and add another service locator (unity, castle windsor etc.) in without changing anything else about your app.

Dependencies should not be resolved from two places as seen in your second option, and not only via the UI project in the third option (what happens if you swap out your UI project and put a different one in then?).

Bradfield