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

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

似乎是，MVC模型本身已经分配了需要并通过分层架构实现的关注点的分离。有人可以在这个问题上说一下吗？

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

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

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

解决方法

我也在努力解决如何以正确的方式构建应用程序的问题。
在洋面建筑之后，我听到有关于here(特别是图像发现here)，我的解决方案看起来像这样：

> Project.Core
业务逻辑/服务实现，实体，必须由其他项目实现的接口(即“IRepository”，“IAuthenticationService”，…)
> Project.Data
数据库连接 – 在我的情况下，NHibernate存储库和实体映射到这里。
实现Project.Core的数据接口
> Project.UI.Web
Asp.Net MVC(“presentation”)项目 – 将整个应用程序连接在一起。
具有Project.Core中的接口的实现，并将它们(以及来自Project.Data的)与一些DI框架(如Castle Windsor)连接起来。

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

>它的模型只有(！)viewmodels
>视图使用自己的viewmodel(one-view-one-viewmodel)
>控制器只需要验证输入，将其转换为域对象(由于业务逻辑对于视图模式无非常了解)，并将实际工作(业务逻辑)委派给业务服务。

概要：
如果你遵循这个模型，那么专注于Project.Core是有帮助的，那就是真正的应用程序。它不担心数据的真实持久性，也不关心如何呈现数据。它只是关于“如何做”。但是它规定了其他项目必须提供实施的规则和契约(接口)。

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

LGwarappa

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!