我们有一个框架，定义了许多接口和一些基本的默认实现。我们称之为CompanyFramework。我有一些ASP.NET MVC扩展，目前存储在一个单独的项目CompanyFramework.Web.Mvc中。这样做的原因是，使用核心框架但与MVC无关的应用程序不必引用ASP.NET MVC库。我真的不喜欢这个设置，因为额外的程序集只包含3-4个类文件，但它是避免将不必要的依赖项引入主框架程序集的最简洁方法。
现在，我们有一些用于ASP.NET MVC的特定于StructureMap的扩展，即自定义控制器工厂和模型绑定器类型的东西。你会把这样的东西放在哪里？我可以将它放在CompanyFramework.Web.Mvc项目中，但是任何使用它的ASP.NET MVC项目都会引用StructureMap程序集，即使它没有被使用。我也可以创建一个单独的CompanyFramework.StructureMap项目，但是如果我开发了不依赖于ASP.NET MVC的StructureMap的任何扩展，我仍然会为使用它们的类引用MVC程序集。
我应该单独创建一个CompanyFramework.Web.Mvc.StructureMap项目吗？这种方法总体上看起来最干净，但我觉得我开始引入一堆混乱整个项目结构的轻量级卫星组件。
答案 0 :(得分：2)
更糟糕的是，糟糕的依赖关系还是少数额外的项目？稍微混乱的IDE是一个很好的代价，一个明确定义的结构。
答案 1 :(得分：1)
在这样的任何问题上，我发现考虑该决定对未来修改的长期影响是有帮助的。最终，其中一些库将被淘汰并被替换，而其他库将继续存在。例如，有些技术将取代MVC。
我相信将这些东西分开将使未来的开发人员和维护人员的生活变得更加容易。依赖关系将更加明确（这总是一件好事），并且可以更加自信和清晰地做出迁移决策。
此外，由于许多其他原因，一个不断扩展的Big Ball of Mud图书馆并不是你想要在未来的每个项目上实现的。对我来说，“一堆轻量级组件”听起来像是一个很好的设计目标。
答案 2 :(得分：0)
我建议将StructureMap与MVC项目一起使用。我认为这在逻辑上是最有意义的，并且在某些情况下使用未使用的引用不会成为问题。
我认为您当前的设置（CompanyFramework assembly + MVC程序集）非常合理。我发现我最终会遵循相同的模式：一个通用程序集，一个Web程序集（或专门针对MVC或Web表单），一个数据库程序集等。在这样的高功能级别上分离它们是一个好的起点。