如何将大型 MVC 4 应用程序划分为多个较小的应用程序？

Question

我有一个“ ASP.NET MVC 4 Web 应用程序”，在 Visual Studio 2013 中分为多个区域。

该项目变得越来越大，以至于我目前在应用程序中拥有大量区域。

有一个特定区域可以在另一个 MVC 4 应用程序中单独分离。我创建了一个新的 MVC 4 应用程序，并将该区域移至该应用程序。

这些是我面临的问题：

1. 移动的区域使用原始应用程序中其他类的代码。具体来说，有一个共享区域，其中包含一些属性以及一个BaseController。
2. 移动区域的视图也使用了JS脚本和其他内容。大多数时候，所使用的脚本并不排斥或特定于使用它们的区域。因此，内容在许多领域之间相互引用。

这是我尝试过的：

1. 为了解决编译错误，我尝试将旧 MVC 应用程序的引用添加到新 MVC 应用程序，以便新应用程序中的类可以看到旧应用程序中的其他类，例如共享区域中的类。然而，这似乎并没有解决问题。
2. 为了修复 JS 脚本和内容问题，我创建了一个解决方案文件夹并将所有脚本移至其中。但是，我无法验证这是否有效，因为由于编译错误我可以启动应用程序。

这是我的问题：

1. VS2013 是否提供了一些工具来分离 MVC 应用程序或使应用程序引用另一个应用程序的代码和内容？
2. 您认为进行这种分离的最佳策略是什么？

我尝试在 SO 和 Google 上搜索如何实现这种分离。然而，我发现的似乎适用于以前版本的MVC和VS。由于我对 MVC 领域和一般 MVC 的概念很陌生，所以我无法解决这个问题。

Answer 1

我会对这个问题采取更普遍的观点。这并不是一个具体的 ASP.NET MVC 问题，而是一个 .NET 代码组织问题。我不相信有任何一种特定的规范方法，而是一些通用指南可以根据您的喜好以及您的项目/团队的工作方式提供帮助。

我关注的总体项目是将代码拆分为单独的程序集并创建资产管道。

拆分程序集允许您的项目根据需要独立编译和重新编译。如果您需要在 Web 服务中跨计算机拆分内容并在其他相关项目（例如 WCF 服务）中重用，或者如果您需要根据您的要求执行 GAC 特定程序集之类的操作，那么这会带来额外的好处。

将事物放入管道只会使共享和管理一切变得更加容易。

以下是一些建议：

• 您的解决方案中不需要 1 个整体项目来完成听起来像您所拥有的一切。将事物分成多个项目，从而产生多个程序集。您还可以为不需要其他部分运行的应用程序的独立部分提供多个解决方案。

• 从整个应用程序共享的任何“后端”和“业务”逻辑开始。例如，如果您有一个由多个视图使用的 CustomerService 类，请将其放入类似 MyCompany.MyApp.Services 的内容中。显然，如果您最终添加大量项目，您获得的粒度越细，您的命名可能会越具体。

• 特别是对于 MVC 类型的项目，通常很容易将模型拆分为 1 个或多个程序集。示例：MyCompany.MyApp.SomeGroupingName1.Models 和 MyCompany.MyApp.SomeGroupingName2.Models，或简单地转换为 1 作为 MyCompany.MyApp.Models

• 您也可以将控制器拆分为多个程序集，与上一点相同。

• 您也可以将 UI 中的任何类型的组件抽象为它们自己的程序集，视图也是如此。

• 使用您提到的解决方案文件夹。

• 如果需要，可以引入资产管理库来帮助构建和解决资源捆绑问题。如果库尚未执行此操作，您可以创建一个资产管道，将其插入其中以缩小 css 和 js。然后，在您的应用程序中，您只需在所需的页面中引用所需的捆绑包，而不是总是在每个页面手动包含所有内容或在整个应用程序中共享整个站点中的所有内容。

• 如果可能的话，优先选择组合而不是继承。从你的帖子中还不清楚，但我看到人们试图为每个控制器、视图等实现一个规则所有基类的许多问题。正如他们所说，它可能会起作用，直到它不起作用。使用基类和继承仍然是一个好主意，但不要将执行不同操作的多个事物绑定到同一基实现。那时，如果您需要执行某种契约，那么接口可能更适合您。

最后一点：如果您将内容捆绑在内容管道中，如果操作正确，客户端会最大限度地减少下载脚本的次数，并且您可以让浏览器尝试为其他页面缓存它。有时，最好将一个大文件推送一次，而不是在每个页面上建立许多网络连接到不同的文件，这些文件不容易被缓存或内联在视图中。