MVC3 何时使用区域？
我正在开发一个敏捷的 MVC3 项目，它开始变得相当大，特别是我的管理部分，用户可以在其中设置很多配置等。这是我的第一个 MVC3 项目，所以我很好奇它什么时候会出现使用区域有意义吗？
比如，在您决定将管理等特定部分的控制器划分为一个区域并为各个管理操作创建控制器之前，该控制器应该有多大？
另外，在使用区域时，我应该重构为对所有内容使用区域，还是仅对需要区域的部分使用区域？
I am working on an agile MVC3 project and it is starting to get rather large, specifically my management section, where the user is able to set a lot of configurations, etc. This is my first MVC3 project, so I am just curious when it makes sense to use areas?
Like how large should a controller for a specific section like management be before you decide to break it up into an area and create controllers for the individual management operations?
Also, when using areas, should I refactor to use areas for everything, or just for the sections that need an area?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有多少开发者，关于如何组织这个的意见就有多少，但我的观点如下；
控制器应该只负责与视图交互。也就是说，实例化和填充模型对象，从业务对象或数据访问层检索数据，响应来自页面的任何请求（表单提交、AJAX 请求、动态资源创建方法/类的接口（例如创建验证码或其他动态）如果你坚持这一理念，它们的大小和复杂性永远不应该超过你的观点。
区域 我倾向于使用区域将应用程序分解为子应用程序。例如，一个网站可能有一个讨论论坛、产品目录、公司信息、支持数据库等，所有这些都是单独的区域：
然后，在每个区域中，您可能有
等等。
就像在 Webforms 网站中，每个文件夹代表网站的一个独特的“区域”，区域提供了另一个级别的组织，使您可以将相关的控制器、视图等保留在公共位置，并且应该以类似的方式使用。
There are as many opinions about how to organize this as there are developers, but my views are as follows;
Controllers should only be responsible for interacting with views. That is, instantiating and populating model objects, retrieving data from your business objects or data access layer, responding to any requests from the page (form submissions, AJAX requests, interface to dynamic resource creation methods/classes (such as creating CAPTCHAs or other dynamic images)), etc. If you stick to that philosophy, their size and complexity should never exceed that of your views.
Areas I tend to use areas to break up the application into sub-applications. For instance, a site may have a discussion forum, product catalog, company information, support database, etc, all of which would be separate areas:
Then, in each area, you might have
etc.
Just as in a webforms site where each folder represented a distinct "area" of the website, areas provide another level of organization that lets you keep related controllers, views, etc in a common location, and should be used in a similar fashion.
我们使用区域来区分应用程序中值得注意的单独关注点。特别是单独的关注点可能需要每个区域的唯一身份验证或布局/样式。例如，我正在开发一个具有各种“模块”的应用程序。每个模块都是一个 mvc 区域，每个模块作为一个设置部分也是一个 mvc 区域。该应用程序具有三个模块，因此总共有六个区域 - 具有六个用户权限。这允许每个模块都有一个新的“母版页/布局”（外观）和特定的安全级别。
它也有助于分离代码； AreaA 中的代码与 AreaB 中的代码无关，但有时 AreaA 和 AreaB 使用在项目根目录中找到的公共代码。
站点的非区域部分包括用户登录、错误页面（404 等）、进入模块的主“启动器”区域、异常处理以及其他横切任何网站的包含内容。 MVC领域。
We use areas to distinguish notable separate concerns within the application. Especially separate concerns that may require unique authentication or layout/styling for each area. For example, I'm working on an application that has "modules" of sorts. Each module is an mvc area and each module as a setup section that is also an mvc area. The application has three modules, so that is a total of six areas -- with six user rights to go along with them. This allows each module to have a new "master page/layout" (appearance) and a specific security level.
It helps in separating the code as well; code in AreaA has nothing to do with code in AreaB, but sometimes AreaA and AreaB use common code found in the root of the project.
The non-area parts of the site have things like the user-login, error pages (404, etc), the main "launcher" area to enter the modules, exception handing, and other encompassing things that cross-cut across any of the mvc areas.
当您需要单独控制和重用控制器名称时，它最实用。就像您可以将它用于管理网站、博客部分等。
Its most practical when you need separate control and reusing controller names. Like you could use it for an administration site, a blog portion, etc.