asp.net-mvc - MVC Areas、MvcCodeRouting、两者，还是其他架构？

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

MvcCodeRouting NuGet 包非常引人注目，我计划使用它。但是，我不确定使用 MVC 区域是否明智。如果使用 MvcCodeRouting，MVC Areas 似乎是多余的，但我不确定 Areas 提供的额外代码组织是否仍然需要。

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

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

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

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

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

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

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

最佳答案

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

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

选项#1

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

MvcCodeRouting 不会更改的一件事是 Views 文件夹的位置。

关于asp.net-mvc - MVC Areas、MvcCodeRouting、两者，还是其他架构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14280045/