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

Question

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

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

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

这些是我面临的问题:

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

这是我尝试过的:

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

这是我的问题:

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

我尝试在 SO 和 Google 上搜索如何实现这种分离。但是，我发现的似乎适用于以前版本的 MVC 和 VS。由于我是 MVC 领域和 MVC 概念的新手，所以我无法解决这个问题。

Answer 1

我会从更一般的角度看待这个问题。这不是一个特定的 ASP.NET MVC 问题，而是一个 .NET 代码组织问题。我不相信有任何一种特定的规范方法，而是一些通用的指导方针，可以根据您的偏好和您的项目/团队的工作方式提供帮助。

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

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

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

这里有一些建议:

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

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

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

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

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

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

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

• 尽可能使用组合而不是继承。从你的帖子中看不清楚，但我已经看到很多问题，人们试图为每个 Controller 、 View 等实现一个规则，它们都是基类。正如他们所说，它可能会起作用，直到它不起作用。使用基类和继承仍然是一个好主意，但不要将做不同事情的多个事情绑定(bind)到同一个基础实现。到那时，如果您需要执行某种契约，接口(interface)可能更符合您的需要。

最后一点:如果您将内容捆绑在您的内容管道中，如果您做得对，客户端可以最大限度地减少他们下载您的脚本的次数，并且您可以让浏览器尝试为其他页面缓存它。有时将一个大文件下推一次比在每个页面上建立许多网络连接到不同的文件更好，这些文件不容易缓存或在您的 View 中内联。