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

Question

我们有一个框架定义了许多接口和一些基本的默认实现。我们称之为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项目吗？这种方法总体上看起来最干净，但我觉得我正在开始引入一堆混乱整个项目结构的轻量级卫星组件。

Answer 1

对于任何这样的问题，我发现考虑未来修改决定的长期影响是有帮助的。最终，这些图书馆中的一部分将被废弃并被取代，而另一些将继续生存下去。例如，一些技术将会取代MVC。

我相信将这些东西分开将使未来的开发人员和维护人员的生活变得容易很多。依赖关系将更加明确（这总是一件好事），迁移决策可以更加自信和清晰。

此外，一个不断扩大的泥浆大球库不是你想要在未来的每一个项目上因其他原因而需要处理的东西。 “一堆轻便的组件”听起来像是我设计的一个优秀目标。

Answer 2

更糟糕的是，糟糕的依赖或少量的额外项目？一个稍微混乱的IDE是一个很好的定义结构的小价格。

Answer 3

我建议将StructureMap与MVC项目结合使用。我认为这在逻辑上是最有意义的，并且在某些情况下使用未使用的参考不会成为问题。

我认为你目前的设置（CompanyFramework程序集+ MVC程序集）是非常合理的。我发现我最终会遵循相同的模式：一个常见的程序集，一个Web程序集（或专门针对MVC或Web表单），一个数据库程序集等。在这样的高级功能级别上分离它们是好的地方开始。