asp.net-mvc - 企业的 MVC 领域——好还是坏？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




当您有很多 Controller 时，在单个项目解决方案中引入区域确实可以提高分离度，并允许将模块轻松复制到解决方案中或从解决方案中复制出来。然而，在大型企业解决方案中，我更倾向于将逻辑拆分为单独的项目。

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

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

Answer 1

我不确定这是否是正确的问题。 区域对于小型项目来说可能是多余的，但很难想象一个非平凡的大型项目不使用区域来帮助保持类井井有条。

我在企业中使用 MVC 领域，并且喜欢它的几件事 :

通常，人们正在研究给定域内的功能(例如，搜索、结帐等)。如果区域名称与您的业务领域相对应， MVC 区域有助于减少实现功能所需的时间 ，因为相关的类很容易找到。

MVC 路由为您提供了极大的灵 active 关于如何构建 URL。我以前用Action Controller "pattern"但是对于面向非公开的 URL，我刚刚完全接受了 Area 默认路由以使事情变得简单。

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

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

但是随着 Web 项目的增长，MVC 区域非常擅长为 UI/路由困惑提供一些秩序，这对我来说是无价的，无论上下文如何。