ASP .NET MVC 架构如何适应传统的多层架构

Posted 2023-03-08

【中文标题】ASP .NET MVC 架构如何适应传统的多层架构

【英文标题】：How ASP .NET MVC architecture fits into the traditional multi layered architecture

【发布时间】：2011-08-24 20:22:30

【问题描述】：

从使用业务层、服务层、数据访问层和表示层构建 Web 应用程序的传统方式转变为 MVC 设计模式，我发现很难理解它如何适应旧模型。

似乎 MVC 模型本身已经完成了通过分层架构实现所需和过去的关注点分离。有人可以解释一下这个问题吗？

作为参考，以下是我的理解，请分享您对此的看法

MVC 视图和控制器以及视图模型 - 表示层

MVC 模型 - 可以是 - 数据访问层或业务层甚至服务层

【问题讨论】：

How MVC (ASP.NET MVC) band 3-tier architecture can work together? 的可能重复项

这不是重复的，因为另一篇文章更多地从物理分离的角度而不是概念分离的角度讨论了 3 层架构。

【参考方案1】：

我只将 Asp.Net MVC 部分视为整个应用程序的 视图（或演示）部分。

我也为如何以正确的方式构建应用程序的问题苦苦挣扎。 遵循 洋葱架构，我听说过 here（尤其是找到的图片 here），我的解决方案如下所示：

Project.Core

必须由其他项目实现的业务逻辑/服务实现、实体、接口（即“IRepository”、“IAuthenticationService”……）

Project.Data

数据库连接 - 在我的例子中，NHibernate 存储库和实体映射位于此处。 实现 Project.Core 的数据接口

Project.UI.Web

Asp.Net MVC（“演示文稿”）项目 - 它将整个应用程序连接在一起。 在 Project.Core 中实现接口，并将它们（以及来自 Project.Data 的接口）与一些 DI 框架（如 Castle Windsor）连接起来。

Project.UI.Web 遵循以下约定：

它的

models

只是(!)

viewmodels

视图

使用他们的

自己的视图模型

（one-view-one-viewmodel）

控制器

只需要

验证

输入，

转换

成

领域对象

（作为业务逻辑

对视图模型一无所知

）并将真正的工作（业务逻辑）

委派

给业务服务。

总结： 如果您遵循此模型，则专注于 Project.Core 会有所帮助： 是真正的 应用程序。它不担心数据的真正持久性，也不关心它是如何呈现的。这只是关于“如何做”。但它列出了其他项目必须为其提供实现的规则和合同（接口）。

我希望这对您如何布局 Asp.Net MVC 应用程序有所帮​​助！

Lg 瓦拉帕

【讨论】：

我不明白服务实现是如何进入核心的。它不应该在 Project.Core 之外吗？这样可以防止意外紧密耦合到 svc 而不是 svc 接口。

在您的 Project.UI.Web 中，您已实现的 Project.Core 接口的示例是什么？

【参考方案2】：

正如其他人所说，它并没有太大变化。我的应用通常是这样设计的：

模型层（域和视图模型） 存储库层（数据访问） 服务层（有时实现 作为 WCF 服务，具体取决于 应用程序/要求） 服务器端 MVC 层（Asp.net MVC 本身） 客户端 MVVM 或 MVC（通过 Knockout.js、Backbone.js 或 Spine.js)

在服务器端 MVC 层，我的控制器方法很轻。他们通常调用服务层对象上的方法来获取一些数据并将其作为 Json 数据传递给客户端。

因为我是把Json送回来，所以我的观点也很淡很稀疏。通常只包含将使用客户端模板库呈现的脚本包含和模板。

【参考方案3】：

简而言之：没有太大变化。

我只熟悉几种演示模式：MVP（模型、视图、演示者，常见于 windows forms/asp.net）、MVC（模型、视图、控制器）和 MVVM（模型、视图、视图模型， WPF/Silverlight 中常用）。

链接：http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

以上链接应该回答您的一些（如果不是全部）问题。

我通常编写 ASP.NET MVC 应用程序的方式是至少包含一个用于 CRUD 操作的服务/业务层混合（因为数据访问既不属于视图模型也不属于控制器，而且绝对不属于视图！）。

【讨论】：

如果使用enitiy框架呢？它确实以一组易于管理的 MVC 数据模型的形式为您提供了抽象。那么您是否需要额外的数据访问层？

Automapper 之类的东西可用于将 EF 的实体映射到您的域模型。我建议将域模型保留在 MVC 模型命名空间之外，并将它们放在自己的程序集中。

【参考方案4】：

非常基本的解释：

如果您创建一个新的 MVC 应用程序，您将自动获得一个 Controllers、Models 和 Views 文件夹。

您的控制器就像您的业务层一样 模型是数据访问/服务层 视图是表示层。

请参阅http://www.asp.net/mvc 以获得完整的详细说明。

【讨论】：

控制器不是业务层。事实上，控制器应该尽可能的薄

我和@psousa 一起讨论这个问题，事实上微软建议在控制器中根本没有任何业务逻辑，并在模型中处理所有这些。