MVC企业领域 - 好还是坏？

Question

在单个项目解决方案中，当您拥有大量控制器时，引入区域确实可以改善分离，并且可以轻松地将模块复制到解决方案中或从解决方案中复制出来。但是，在大型企业解决方案中，我倾向于将逻辑拆分为单独的项目。

因此具有单独的UI，Controller，SOA，Model和Repository项目。在这种情况下，区域不再有意义了，加上它们会为Url添加一个额外的顶级，这通常是不需要的，但我相信如果保持控制器的独特性，你可以省略Url中的区域，但不是有点臭吗？

也许区域适用于中等复杂度的网站，或者模块代码更好地保存在一个位置，以便可以将其复制到其他网站或删除。

Answer 1

我不确定这是不是正确的问题。小型项目的区域可能过度，但很难想象一个非平凡的大型项目没有使用区域来帮助保持课堂组织。< / p>

我为企业使用MVC区域并喜欢它的一些事情：

1. 通常人们正在处理给定域内的功能（例如，搜索，结帐等）。如果区域名称与您的业务域相对应， MVC区域有助于减少实现功能所需的时间，因为相关类很容易找到。
2. MVC路由为您提供了很多灵活性，而不是如何构建网址。我过去常常使用Action Controller "pattern"，但对于非公开的网址，我只是完全接受了区域默认路由，以简化操作。
3. 区域为您提供了样式的独特优势，更重要的是，在站点级别封装行为。每个区域都有自己的Web配置，您可以在其中控制基本视图页面或添加托管处理程序。

在一个多客户端可以访问公共业务功能的环境中，您完全可以将服务放在单独的项目/解决方案中，从而通过存储库抽象数据访问。

但是随着网络项目的发展，MVC领域非常擅长为UI /路由混乱提供一些订单，对我而言，无论上下文如何，这都是非常宝贵的。

Answer 2

首先，在我回答之前，这只是我的意见，而且主要是关于模型。

我看到它的方式，区域可能是如此邪恶..如果你有很多区域你的解决方案探险家变成了一个迷宫，它很难找到一些东西。

我建议在您的解决方案中创建一个新的库项目，并将逻辑放在那里。

最好的好处（并不是你可以找到更容易找到的东西）是你的应用程序变得更加模块化。如果您在ASP.NET MVC应用程序中创建了一个库并为其指定了引用，则不能容易出错，并在逻辑中涉及UI。