asp.net-mvc - MVC 区域，MvcCodeRouting，两者，还是其他一些架构？

Question

我正在整理一个 MVC 4 项目，该项目可能会在 future 几年内广泛发展。有了从头开始的奢侈和挑战，我试图找出路由和组织我的 Controller 和 View 的最佳实践。

MvcCodeRouting NuGet 包很有吸引力，我打算使用它。但是，我不确定使用 MVC 区域是否也是明智的。如果使用 MvcCodeRouting，似乎 MVC 区域是多余的，但我不确定区域提供的额外代码组织是否仍然是可取的。

为了说明我的意思，让我们以这个虚构的评分应用程序为例。它具有以下高级领域:

公共(public)门户

认证学生门户

认证老师传送门

认证管理员门户

假设每个门户最终会有 100 个不同的 View (让我们雄心勃勃!)。如果实现了这种规模，MVC 区域似乎是划分代码的好方法，在每个区域中使用 MvcCodeRouting。或者也许我们应该按照我们喜欢的方式组织代码，让 MvcCodeRouting 完成繁重的工作。

因此，Areas plus MvcCodeRouting 设计看起来像这样(文件夹结构):

MvcWeb项目

领域

行政

Controller

型号

浏览量

上市

Controller

型号

浏览量

学生

Controller

型号

浏览量

老师

Controller

型号

浏览量

内容

Controller

脚本

浏览量

没有区域的 MvcCodeRouting 设计看起来像这样(文件夹结构):

MvcWeb项目

内容

Controller

管理员

公众号

学生

教师

楷模

管理员

公众号

学生

教师

脚本

意见

管理员

公众号

学生

教师

这些设计中隐含的是 MvcCodeRouting 将用于通过命名空间进一步组织类。

在这些设计中，哪个是更好的方法？为什么？还有另一种更好的方法吗？在一种设计或另一种设计中，在门户之间共享资源是更容易还是更困难？

请注意，这只是整个代码解决方案的前端，因此其背后的整个服务/域/数据库都有自己的特定架构。出于这个问题的目的，我只是对如何在 MVC 中构建这些不同的应用程序领域感兴趣。

Answer 1

我不会将区域仅用于文件夹组织。使用 MvcCodeRouting 完全不需要区域，因为您可以使用命名空间来代替，并且同时使用两者可能会造成混淆。

让我建议您可以与 MvcCodeRouting 一起使用的其他文件夹结构:

选项 #1

MvcWeb项目

行政

Controller

型号

上市

Controller

型号

学生

Controller

型号

老师

Controller

型号

意见

管理员

公众号

学生

教师

内容

脚本

选项 #2
在这一点上，您可以将 ViewModels 放在与使用它的 Controller 相同的目录/命名空间中。

MvcWeb项目

Controller

管理员

公众号

学生

教师

意见

管理员

公众号

学生

教师

内容

脚本

MvcCodeRouting 没有改变的一件事是 Views 文件夹的位置。