如何在ASP.NET MVC应用程序中建立分层

Question

我将要在.NET中开发MVC应用程序，并通读许多文章。我对应用程序的分层感到非常困惑。一种想法是关于为每个层创建单独的项目，而另一些想法则是在同一项目内创建文件夹。我正在努力理解采用这两种方法的优缺点。您能说明哪个选项更好，为什么？

Answer 1

如果您创建单独的项目，将很难理解， 尝试根据类别创建其他文件夹

Answer 2

将视图和控制器放在同一ASP.NET MVC项目中。对于模型，这取决于。特定于您的应用程序的类（对其他应用程序无用）也应放在ASP.NET MVC应用程序项目中。但是，应该将对其他应用程序有用的类放在单独的项目中。

不要太担心将模型类放在何处。您可以随时重构它们。这是正常的软件维护。

Answer 3

在这一点上没有对与错，但是这些方法各有利弊。

多个项目

要了解人们为什么要这样做，您需要了解应用程序如何在桌面上构建。通常，桌面应用程序具有很多类，因此人们将所有内容都放在单独的项目中，以便更好地查看代码。这样做的另一个好处是，当您更改某些内容时，不必在慢速计算机上编译整个代码库。第二件事是您可以在多个应用程序（例如域层）之间共享代码。您的桌面应用程序和服务器应用程序具有一些公共层。这在现代Web开发中并不常见，并且不建议在不同应用之间共享代码，因为一个应用中的更改可能会导致回归。由于项目将编译为单独的dll（如果您未配置其他内容），这可能允许您执行一个插件系统，在该系统中，您可以在运行时加载dll，并且服务器上没有任何停机时间，但这需要模块化体系结构拔下来。 这样做的好处是，在大多数情况下，您可以切换高层而不用更改基本层。 想象一下您拥有常见的传统图层

• DataAccess
• BusinessLogic
• UI

理论上，您可以交换任何UI层而不必对其他两层进行任何更改，并且让新的UI项目仅引用旧项目，例如，如果您从mvc更改为signalr或南希同样，您可以交换数据访问层，而不必在UI层中进行任何更改。如果将所有内容保留在同一个项目中，这将更加困难，因为如果不重构代码或将代码从一个项目复制到另一个项目，就无法摆脱MVC依赖性。

单个项目

这在小型代码库中很常见，因为它很简单，不需要任何项目，您只需创建一个新的网站项目并开始实现我们的逻辑即可。但是，如果您的应用变大，则编译可能会很慢，但在现代快速计算机上可能不会那么明显。 这种方法在微服务领域很常见，在这种情况下，您不希望您的项目具有多个dll，并且希望将其保持在尽可能小的状态。由于在实际项目中几乎几乎会发生层交换，因此您无需为此而精打细算。

此外，由于数据库的性质不同，因此很难抽象化诸如数据访问层之类的东西。一种支持的东西可能不会被另一种支持，我曾经不得不从NHibrenate更改为Entity Framework，您会感到惊讶的是，对一个在另一个上不起作用的东西不起作用，我认为人们试图改变EF到EF核心也可以证明这一点。这也将导致性能问题，因为几乎不可能通过抽象来最大化性能。

正如我所说，这主要是一种意见，因此没有写或错。我可以告诉您的其他事情是，我几乎完全停止了推荐分层体系结构，并开始使用要素体系结构。对我来说，这更有意义，并且非常适合现代敏捷和/或混乱的公司工作方式。 Check out Jimmy Bogard he has multiple talks about the subject。