.NET项目/命名空间组织问题

我们有一个框架，它定义了许多接口和一些基本的默认实现。让我们称之为公司框架。我有一些ASP.NET MVC扩展，目前存储在单独的项目公司framework.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项目？总体而言，这种方法似乎是最干净的，但我觉得我开始引入一些轻量级的附属程序集，这些程序集扰乱了整个项目结构。

更糟糕的是，不好的依赖关系还是一些额外的项目？稍微凌乱的IDE对于定义良好的结构来说是一个很小的代价 我相信，将这些事情分开将使未来的开发人员和维护人员的生活更加轻松。依赖关系将更加明确（这始终是一件好事），并且可以更加自信和清晰地做出迁移决策

---

此外，一个不断扩大的大泥球库并不是你将来因为很多其他原因想在每个项目上都加上的东西。“一堆轻量级组件”对我来说似乎是一个极好的设计目标。

我建议将StructureMap与MVC项目结合起来。我认为这在逻辑上是最有意义的，在某些情况下，拥有未使用的引用不会是一个问题

---

我认为您当前的设置（CompanyFrameworkAssembly+MVC assembly）非常合理。我发现我最终会遵循同样的模式：一个普通程序集、一个web程序集（或专门针对MVC或web表单）、一个数据库程序集等等。从这样一个高功能级别将它们分开是一个很好的起点。

如果这是一个问题，可以始终使用解决方案文件夹来管理IDE混乱。