Geek asks and answers

Project / .NET namespace organization issue

We have a structure that defines many interfaces and some basic default implementations. Let me call it CompanyFramework. I have some ASP.NET MVC extensions that are currently stored in a separate CompanyFramework.Web.Mvc project. The reason for this is because applications that use the basic structure but have nothing to do with MVC should not reference ASP.NET MVC libraries. I do not really like this setting, since the additional assembly contains only 3-4 class files, but it was the cleanest way to avoid introducing unnecessary dependencies into the assembly of the main structure.

Now we have some extensions specific to StructureMap that we use for ASP.NET MVC, namely: custom controller factories and the type of the type of binding type. Where would you put something like that? I could just drop it in the CompanyFramework.Web.Mvc project, but then any ASP.NET MVC project that uses this will have a reference to the StructureMap assembly, even if it is not used. I could also create a separate CompanyFramework.StructureMap project, but then if I ever create extensions for StructureMap that are independent of ASP.NET MVC, I will still suck MVC assembly references for classes that use them.

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

+3
source share
3 answers

For any issue like this, I find it useful to consider the long-term consequences of the decision regarding future modifications. In the end, some of these libraries will become obsolete and replaced, while others will live. Some technologies will come that will replace MVC, for example.

, . ( ), .

, Big Ball of Mud -, . " " .

+1

, ? IDE - .

+2

StructureMap MVC. , , .

I think your current setup (CompanyFramework build + MVC build) is pretty reasonable. I found that I ended up following the same type: general assembly, web assembly (or specifically designed for MVC or web forms), database assembly, etc. Separating them at a high functional level is a good place to start.

0
source

More articles:


All Articles