.NET project / namespace organization question

We have a framework that defines many interfaces and some basic default implem开发者_如何学Pythonentations. Let's call it CompanyFramework. I have some ASP.NET MVC extensions, currently stored in a separate project CompanyFramework.Web.Mvc. The reason for this is so that applications that use the core framework but have nothing to do with MVC don't have to reference the ASP.NET MVC libraries. I don't really like this setup, as the extra assembly only contains 3-4 class files, but it was the cleanest way to avoid introducing unnecessary dependencies to the main framework assembly.

Now, we have some StructureMap-specific extensions we use for ASP.NET MVC, namely custom controller factories and model binder type stuff. Where would you put something like that? I Could just throw it in the CompanyFramework.Web.Mvc project, but then any ASP.NET MVC project that uses that would have a reference to the StructureMap assembly, even if it isn't being used. I could also create a separate CompanyFramework.StructureMap project, but then if I ever develop any extensions to StructureMap that don't depend on ASP.NET MVC, I'm still suck with referencing the MVC assemblies for the classes that do use them.

Should I make a separate CompanyFramework.Web.Mvc.StructureMap project? This approach seems cleanest overall, but I feel like I'm starting to introduce a bunch of lightweight satellite assemblies that are cluttering the overall project structure.

What's worse, bad dependencies or a handful of extra projects? A slightly cluttered IDE is a small price to pay for a well defined structure.

On any question like this I find it is helpful to consider the long-term implications of the decision with respect to future modifications. Eventually, some of these libraries will be obsolesced and replaced, while others will live on. Some technology will come along that will replace MVC, for example.

I believe that keeping these things separate will make the lives of those future developers and maintainers a lot easier. The dependencies will be more explicit (which is always a good thing), and migration decisions can be made with greater confidence and clarity.

Also, an ever-expanding Big Ball of Mud library is not something that you will want to tack on to every project in the future for lots of other reasons. A "bunch of lightweight assemblies" sounds like an excellent design goal to me.

I recommend putting StructureMap with the MVC project. I think this logically makes the most sense and having that unused reference in some cases will not be a problem.

I think your current set up (CompanyFramework assembly + MVC assembly) is pretty reasonable. I've found that I end up following that same sort of patter: a common assembly, a web assembly (or specifically targeted to MVC or web forms), a database assembly, etc. Separating them at a high functional level like this is a good place to start.