3

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

4

3 回答 3

2

更糟糕的是，糟糕的依赖关系或一些额外的项目？稍微杂乱的 IDE 是为定义良好的结构付出的小代价。

于 2011-05-13T18:50:19.380 回答
1

对于这样的任何问题，我发现考虑该决定对未来修改的长期影响是有帮助的。最终，其中一些库将被淘汰和替换，而其他库将继续存在。例如，将会出现一些取代 MVC 的技术。

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

此外，由于许多其他原因，您不会希望在未来的每个项目中添加一个不断扩展的 Big Ball of Mud 库。对我来说，“一堆轻量级组件”听起来像是一个出色的设计目标。

于 2011-05-13T19:02:04.840 回答
0

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

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

于 2011-05-13T19:07:23.897 回答