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

Question

从传统的Web应用程序架构方法(包括业务层,服务层,数据访问层和表示层)转向MVC设计模式,我发现很难理解它如何适应旧模型.

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

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

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

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

Answer 1

我将Asp.Net MVC部分仅视为整个应用程序的视图(或演示文稿)部分.

我也在努力解决如何以适当的方式构建应用程序的问题.
按照我在这里听到的洋葱架构(特别是这里的图片),我的解决方案看起来像这样:

• Project.Core
  业务逻辑/服务实现,实体,必须由其他项目实现的接口(即"IRepository","IAuthenticationService",......)
• Project.Data
  数据库连接 - 在我看来,NHibernate存储库和实体映射都在这里.实现Project.Core的数据接口
• Project.UI.Web
  Asp.Net MVC("演示")项目 - 它将整个应用程序连接在一起.
  在Project.Core中实现接口的实现,并将它们(以及来自Project.Data的那些)连接到像Castle Windsor这样的DI框架.

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

• 它的模型只是(!)viewmodels
• 的观点消耗他们自己的视图模型(单视图酮视图模型)
• 该控制器只需要验证输入,转换成域对象(如业务逻辑exacly一无所知的ViewModels),并委托实际工作(业务逻辑)的业务服务.

简介:
如果您遵循此模型,那么关注Project.Core是有帮助的:这是真正的应用程序.它不担心数据的真实持久性,也不关心它是如何呈现的.这只是"怎么做".但它正在规划其他项目必须提供实施的规则和合同(接口).

我希望这可以帮助您如何布局Asp.Net MVC应用程序!

Lg
warappa