14

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

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

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

4

2 回答 2

13

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

我为企业使用 MVC 领域，并且喜欢它的几件事：

  1. 通常，人们正在处理给定域内的功能（例如，搜索、结帐等）。如果区域名称与您的业务域相对应，MVC 区域有助于减少实现功能所需的时间，因为相关类很容易找到。
  2. MVC 路由在如何构建 URL方面为您提供了极大的灵活性。我曾经使用动作控制器“模式”，但对于非公开的 URL，我刚刚完全接受了区域默认路由以使事情变得简单。
  3. 区域为您提供样式的独特优势，更重要的是，在站点部分级别封装行为。每个区域都有自己的 Web 配置，您可以在其中控制基本视图页面或添加托管处理程序。

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

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

于 2012-01-30T17:32:21.267 回答
1

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

在我看来，区域可能非常邪恶。如果你有很多区域，你的解决方案探索器就会变成一个迷宫，而且很难找到一些东西。

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

最大的好处（并不是您可以更容易地找到您正在寻找的东西）是您的应用程序变得更加模块化。如果您在 ASP.NET MVC 应用程序中创建一个库并为其指定一个引用，那么您就不会轻易犯错并在逻辑中涉及 UI。

于 2013-02-07T23:55:55.487 回答