Asp.net mvc ASP.NETMVC体系结构如何融入传统的多层体系结构

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

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

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

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

---

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

非常基本的解释：

如果您创建一个新的MVC应用程序，您将自动获得一个控制器、模型和视图文件夹

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

---

有关详细说明，请参阅。

简言之：没有太大变化

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

链接：

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

---

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

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

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

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

---

因为我将返回Json，所以我的视图也非常轻巧和稀疏。通常只包含脚本和模板，这些脚本和模板将通过客户端模板库呈现。

我认为Asp.Net MVC部分仅作为整个应用程序的视图（或表示）部分

我也在为如何以正确的方式构造应用程序的问题而挣扎。
按照洋葱架构我听说了（尤其是找到的图像），我的解决方案如下所示：

• 项目核心
  必须由其他项目实现的业务逻辑/服务实现、实体、接口（即“IRepository”、“IAuthenticationService”、…）
• 项目数据
  DB连接——在我的例子中，NHibernate存储库和实体映射在这里。 实现Project.Core的数据接口
• Project.UI.Web
  Asp.Net MVC（“演示”）项目—它将整个应用程序连接在一起。
  为Project.Core中的接口提供实现，并将它们（以及Project.Data中的接口）与一些DI框架（如Castle Windsor）连接起来

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

• 它的模型只（！）视图模型
• 视图使用自己的视图模型（一视图一视图模型）
• 控制器只需验证输入，将其转换为域对象（因为业务逻辑完全不了解viewmodels）并将实际工作（业务逻辑）委托给业务服务

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

我希望这能帮助你设计一个Asp.NETMVC应用程序

Lg

---

warappa

控制器不是业务层。事实上，控制器应该尽可能的薄我在这一次使用@psousa，事实上，microsoft建议在控制器中根本不包含任何业务逻辑，并在模型中处理所有业务逻辑。可能的重复不是重复，因为另一篇文章更多地从物理分离角度而不是从概念分离角度讨论了三层体系结构。如果使用enitiy框架会怎么样？它确实以一组易于管理的MVC数据模型的形式为您提供了一个抽象。然后你需要一个传统的数据访问层吗？像Automapper这样的东西可以用来将EF的实体映射到你的域模型。我建议将域模型排除在MVC模型名称空间之外，并将它们放在自己的程序集中。我不明白服务实现是如何进入核心的。它不应该在Project.Core之外吗？这样可以防止意外地紧密耦合到svc而不是svc接口。