Home/ Questions/Q 4621438
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T02:42:04+00:00

We have a framework that defines many interfaces and some basic default implementations. Let’s

  • 0

We have a framework that defines many interfaces and some basic default implementations. 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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0