I am early in development on a new ASP.Net MVC project and I using this project to get into DI. I’m pretty sure that I am going to go with Structure Map, but that isn’t what I am asking about. What I am trying to figure out is how best to organize my solution. Do both the unit test project and the model get a configuration file to map their dependencies or is there one class to rule them all?
Also, are there any newbie traps to avoid before I get too far into this?
Many Thanks, All…..
Update
I should add that when I say “organize the solution”, I’m not referring to the number of files/folders, etc., but rather how to structure the classes that are involved with DI. In particular, how to manage the bootstrapper. I can see where poor phrasing on my part could cause confusion.
To encourage better TDD. Have two testing projects and or namespeaces X.Unit.Tests & X.Integrations.Tests.
I have my DI code in my main project in a “namespace directory” (/Config) but in my integration code tests, I might just call those registries or override if I required in my base fixtures or setups.
E.g.
/Config/ServiceRegistry.cs
/Config/RepositoryRegistry.cs
/Config/Bootstrapper.cs
In global.asax I call Bootstrapper.Init() and this will call x.AddRegistry(new ServiceRegistry()) and so on.
In my unit tests you dont need to be using DI only in your integration tests. In my IntegrationTests e.g. if I’m testing NHibernate through to the database I might initialise SM with RepositoryRegistry in TestSetUp with a helper method just wrappering GetInstance().
I don’t split out to projects .Bootstraper and .Domain until I have absolutely have to… Three projects, X, X.UnitTests, X.Integration if you required more move later. I came from a background/company enforce of having dozens of projects it felt dirty a first reducing but not now, I go hit the grow running quickly and reorganize solutions structure later if required.