0

每个区域都有自己的配置等。因此，随着区域的增加，复杂性和可维护性也会增加。将 MVC 应用程序功能模块化或分区到区域或继续使用传统的控制器/视图方法是否是一个不错的选择？

请提出一个通用的解决方案或更好的方法来构建大型 MVC 应用程序。

4

3 回答 3

1

区域不应该令人困惑，当然也不是多余的。正如您所说，它们允许您将 Web 应用程序划分为更小的功能组。当您的应用程序规模增长并且单个应用程序伞变得笨拙时，这非常有用。

例如，我刚刚完成了一个大型应用程序，该应用程序存储了北美各个零售商的促销数据。美国和加拿大的销售团队是孤立的，但在几乎相同的业务环境中执行他们的任务。

将 Web 应用程序的美国和加拿大部分划分为区域是很有意义的，这对我们来说可以更好地组织事情。每个区域仍然可以在有意义的地方使用相同的组件（存储库、服务等），但是区域带来的隔离允许我们为每个业务组构建单独的控制器和视图，而不是尝试运行一堆逻辑检查以适应用户所在的任何区域。

于 2013-08-21T19:53:52.833 回答
0

以下是 Jess Chadwick、Todd Snyder 和 Hrusikesh Panda 的“Programming ASP.NET MVC 4”中您的方法的可能替代方案：

设计 ASP.NET MVC 应用程序时可以采用多种不同的方法。开发人员可以决定将应用程序的所有组件保留在网站程序集中，或者将组件分离到不同的程序集中。在大多数情况下，将业务和数据访问层分离到与网站不同的程序集中是一个好主意。这样做通常是为了更好地将业务模型与 UI 隔离开来，并使编写专注于核心应用程序逻辑的自动化测试变得更加容易。此外，使用这种方法可以重用来自其他应用程序（控制台应用程序、网站、Web 服务等）的业务和数据访问层。

应该在所有程序集中一致地使用公共根命名空间（例如，company.{ApplicationName}）。每个程序集都应该有一个与程序集名称匹配的唯一子命名空间。图 5-4 显示了 Ebuy 参考应用程序的项目结构。该应用程序的功能分为三个项目： Ebuy.WebSite 包含视图、控制器和其他与 Web 相关的文件；Ebuy.Core 包含应用程序的业务模型；CustomExtentions 项目包含应用程序用于模型绑定、路由和控制器的自定义扩展。此外，该项目还有两个测试项目（未显示）：UnitTests 和 IntegrationTests。

于 2013-08-21T19:54:49.860 回答
0

是否使用区域没有规则，基本上由解决方案架构师来进行估计，使用区域是否会带来好处。

我们最新的项目涉及领域，包括在网站上工作的 3 种不同类型的用户。我们使用控制器命名方案，其中控制器名称与资源名称匹配（即 CategoryController）。

但是，某些资源可能已被所有 3 个用户组以完全不同的方式访问：一个用户组只能列出资源，其他用户组可以管理它们（基本 crud），而第三个用户组（类似管理员）可以执行高级功能比如导出、导入等等……

通过在区域中分离功能，我们通过简单地在区域中装饰控制器以请求特定于该区域的用户类型来减少安全问题，以避免混合权限。在该区域的基本控制器上执行此操作，使事情更加集中。

这就是我们选择区域分离的原因之一。

另一方面，我们经常遇到要求高要求的公共网站和“后台”内部配置网站的情况。对于性能和可扩展性 + 并发问题，我们经常设计可以作为一个项目进行负载平衡的公共网站，以及仅作为第二个项目托管一次的后台网站 - 而不是使用区域。

同样，这只是行业的一种方法，不一定是最佳方法。

于 2013-08-23T14:40:41.063 回答