每个区域都有自己的配置等。随着区域的增加，复杂性和可维护性也会增加。在区域中模块化或分区和MVC应用程序功能是否是一个很好的选择，还是继续使用传统的Controller / View方法？
请建议一个通用的解决方案或更好的方法来构建一个大规模的MVC应用程序。
答案 0 :(得分：1)
区域不应该混淆，当然也不是多余的。正如您所说，它们允许您将Web应用程序划分为更小的功能组。当应用程序的大小增加并且单个应用程序伞变得难以处理时，这非常有用。
例如，我刚刚完成了一个大型应用程序，该应用程序存储了北美各个零售商的促销数据。美国和加拿大的销售团队是孤立的，但他们正在几乎相同的业务环境中执行他们的任务。
将美国和加拿大的网络应用程序部分划分为区域是很有意义的，这对我们来说组织起来要好得多。每个区域仍然可以使用相同的组件（存储库，服务等等），但是带来的隔离区允许我们构建特定于每个业务组的独立控制器和视图，而不是尝试运行一堆逻辑检查以适应用户所在的任何区域。
答案 1 :(得分：0)
以下是Jess Chadwick，Todd Snyder和Hrusikesh Panda的“Programming ASP.NET MVC 4”的替代方法：
设计ASP.NET时有许多不同的方法 MVC应用程序。开发人员可以决定保留所有应用程序 网站组件内部的组件，或单独的组件 不同的集会。在大多数情况下，分开它是个好主意 业务和数据访问层进入不同的程序集 网站。通常这样做是为了更好地隔离业务模型 从用户界面，更容易编写专注于自动化的测试 核心应用逻辑。另外，使用这种方法就可以了 可以重用其他的业务和数据访问层 应用程序（控制台应用程序，网站，Web服务等）。
常见的根命名空间（例如，公司。{ApplicationName}）应该是 一直用于所有组件。每个组件应该有一个 与程序集名称匹配的唯一子命名空间。图5-4 显示了Ebuy参考应用程序的项目结构。该 应用程序的功能分为三个 项目：Ebuy.WebSite包含视图，控制器和其他 网络相关文件; Ebuy.Core包含了商业模式 应用;并且CustomExtentions项目包含自定义 应用程序用于模型绑定，路由和扩展的扩展 控制器。此外，该项目还有两个测试项目（不是 显示）：UnitTests和IntegrationTests。
答案 2 :(得分：0)
没有关于是否使用区域的规则，基本上由解决方案架构师来决定是否应该使用区域提供好处。
我们的最新项目涉及领域，包括在网站上工作的3种不同类型的用户。我们使用控制器命名方案，其中控制器名称与资源名称匹配（即CategoryController）。
但是，所有3个用户组都可以以完全不同的方式访问某些资源：一个用户组只能列出资源，其他用户组可以管理它们（基本crud），而第三个用户组（类似管理员）可以做高级功能，如导出，导入等......
通过分离区域中的功能，我们通过简单地装饰区域中的控制器以请求特定于该区域的用户类型来减少安全问题，以避免混合权限。在该区域的基础控制器上进行操作，使事情更加集中。
这就是我们选择区域分离的一个原因。
另一方面，我们经常遇到要求高要求的公共网站和“后台”内部配置网站的情况。对于性能和可伸缩性+并发性问题，我们经常设计可以作为一个项目进行负载平衡的公共网站，以及仅作为第二个项目托管一次的后台网站 - 而不是使用区域。
同样，这只是业界的一种方法，不一定是最佳方法。