Asp.net mvc 企业MVC领域-好还是坏？

在单个项目解决方案中，当您有许多控制器时，引入区域确实改善了分离，并允许在解决方案中轻松复制模块。然而，在大型企业解决方案中，我倾向于将逻辑拆分为单独的项目

因此，有单独的UI、控制器、SOA、模型和存储库项目。在这种情况下，区域不再有意义，而且它们为Url添加了一个通常不需要的额外顶层，尽管我相信如果保持控制器的唯一性，您可以省略Url中的区域，但这不是有点难闻吗

---

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

我不确定这是否是正确的问题。对于小项目，区域可能是多余的，但是很难想象一个非常大的项目不使用区域来帮助保持课程的组织

我为企业使用MVC区域，并喜欢它的一些方面：

通常情况下，人们在给定域内处理功能（例如，搜索、签出等）。如果区域名称与您的业务域相对应，MVC区域有助于减少实现功能所需的时间，因为相关类很容易找到

MVC路由为您提供了大量灵活的URL结构。我曾经使用过，但对于非公开的URL，我刚刚完全采用了区域默认路由，使事情变得简单

区域为您提供了独特的样式优势，更重要的是，在站点部分级别封装行为。每个区域都有自己的web配置，您可以在其中控制基本视图页面或添加托管处理程序

您完全正确地认为服务应该完全位于单独的项目/解决方案中，在多个客户端可以访问公共业务功能的环境中，通过存储库抽象数据访问

---

但是MVC领域非常擅长在web项目发展过程中为UI/路由混乱提供一些秩序，这对我来说是非常宝贵的，无论上下文如何。

首先，在我回答之前，请注意这只是我的观点，主要是关于模型的

在我看来，这些地区可能非常邪恶。。如果您有许多区域，那么解决方案资源管理器就会变成一个迷宫，并且很难找到一些东西

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

---

最好的好处（并不是你能更容易地找到你想要的东西）是你的应用程序变得更加模块化。如果您创建一个库并在ASP.NET MVC应用程序中为它指定一个引用，您就不会轻易出错并将UI包含在逻辑中。

这可能会引起一些兴趣：。它将允许您将代码分离到多个项目中。我认为您需要的是可移植区域，而不是普通区域。+1，非常好地概述了为什么区域有用。