asp.net-mvc - ASP .NET MVC 架构如何适应传统的多层架构

Question

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

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

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

MVC View 和 Controller 以及 View 模型 - 是 - 表示层

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

Answer 1

我看到 Asp.Net MVC 部分 仅作为 查看(或演示)部分 整个应用程序。

我也为如何以正确的方式构建应用程序而苦苦挣扎。
关注 洋葱架构 我听说了 here (尤其是找到的图像 here )，我的解决方案看起来是这样的:

项目.核心
必须由其他项目实现的业务逻辑/服务实现、实体、接口(interface)(即“IRepository”、“IAuthenticationService”...)

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

的数据接口(interface)

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

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

它的型号只是(!)查看模型

浏览量 消费他们的自己的 View 模型 (一 View 一 View 模型)

Controller 只需要验证 输入，变换 它进入域对象 (因为业务逻辑 对 View 模型一无所知 )和 代表真正的工作(业务逻辑)到业务服务。

摘要:
如果您遵循此模型，对 很有帮助关注Project.Core : 那是 实际应用 .它不担心数据的真正持久性，也不关心它是如何呈现的。这只是关于“如何做”。但它列出了其他项目必须为其提供实现的规则和契约(Contract)(接口(interface))。

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

LG
瓦拉帕