StructureMap n-tier apps

I'm trying to implement StructureMap into my ASP.Net MVC 3 application. My architecture follows n-tier approach where my UI tier talks with my services tier which in turn talks with my business tier which in turn talks with the repository tier. I have data contracts that represent the dat开发者_JAVA百科a flowing through all tiers.

My UI tier should only know about the services tier. My UI should not know of or care about the business let alone the repository or data tiers. Each tier is it's own assembly and I'm using constructor dependency injection to inject the necessary instances (ie I'm injecting the business object into my service constructor and injecting the repository object into the business constructor).

So, if my tiers are in separate assemblies, and the UI assembly where Structure Map resides does not know about the lower tiers, then how do I configure structure map? I'm reluctant to create references in my UI tier to all "lower" tiers that sit behind the services tier. If I do that, then that potentially opens the door for the UI to talk with the database directly which is bad.

Please help.

Thanks

Tom

---

Been there done that. Took idea directly just like You, thinking that avoiding assembly references will resolve everything. I even managed to do what You are trying to with post-build xcopy'ing built dll`s. In reality - that just made it way more confusing than it is supposed to be.

The thing is - references themselves aren't root of evil. It's fine to reference everything from uppermost (UI) assembly. Bad code is what causes trouble.

---

I'm reluctant to create references in my UI tier to all "lower" tiers that sit behind the services tier. If I do that, then that potentially opens the door for the UI to talk with the database directly which is bad.

You should reference all lower tiers into the final ASP.NET application which is where the DI container is configured. All assemblies must be in the bin folder when you deploy, otherwise your application won't work.

The UI layer (the ASP.NET application) doesn't directly talk to the database. If you properly abstracted your services it talks to the service abstraction which in terms talks to the repository abstraction which, depending to how you configured your DI talks to the data store.

---

for structure map to wire up the dependencies all the way down the chain it will need access to all of the assemblies which you are actually going to use.

This doesn't mean that the UI has to reference those though (although this is probably the easiest solution)

You could make you UI reference assemblies which contain only the interfaces it needs, without knowing anything about the implementation of those intferaces (or what dependencies they have)

This would mean that your UI should only know about your service tier interfaces.

But for your application to be able to use all of the various parts together it must know which service implementation to use, and must know which implementation of any dependencies that implementation needs to use, and so on all the way down the line. This should all be done in a single place (global.ashx in an ASP MVC app I think), and this is the only place that any references to either the container or the other implementation classes should exist.

You application is the combination of all your tiers together. It is not your UI alone.

If you don't want to reference those assemblies at all then you could probably configure structuremap through xml, which will probably then load the assemblies dynamically. I'm not certain about that, but it should work I think. Xml config is more cumbersome though.

As long as your service interface is injected into your UI controllers then you should be fairly safe. For someone to use a new dependency from one of the referenced dlls like the db layer, they would have to introduce that interface into the controller and wire it up with structure map, which should be easy to spot.