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

Question

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

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

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

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

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

Answer 1

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

我也在努力解决如何以适当的方式构建应用程序的问题 在洋葱架构之后，我听说 here （尤其是找到here的图片），我的解决方案就是这样：

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

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

• 其模型仅为（！） viewmodels
• 观看使用自己的viewmodel （one-view-one-viewmodel）
• 控制器只需要验证输入，将转换为域对象（作为业务逻辑） 对于viewmodels 以及委托对业务服务的实际工作（业务逻辑）一无所知。

<强>要点：
如果您遵循此模型，那么专注于Project.Core ： 是 real < / em>应用程序。它并不担心数据的真实持久性，也不关心它是如何呈现的。它只是＆＃34;怎么做呢＆＃34;。但它规定了其他项目必须提供实施的规则和合同（接口）。

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

LG
warappa

Answer 2

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

• 模型层（域和视图模型）
• 存储库层（数据访问）
• 服务层（有时实施 作为WCF服务取决于 app / requirements）
• 服务器端MVC Layer（Asp.net MVC本身）
• 客户端MVVM或MVC（通过 无论是Knockout.js，Backbone.js还是 Spine.js）

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

因为我要把Json送回去，我的观点也非常轻盈和稀疏。通常只包含脚本包含和将使用客户端模板库呈现的模板。

Answer 3

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

我只熟悉一些演示模式：MVP（模型，视图，演示者，Windows窗体/ 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操作的服务/业务层混合（因为数据访问既不属于视图模型也不属于控制器，绝对不属于视图！）。

Answer 4

非常基本的解释：

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

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

有关详细说明，请参阅http://www.asp.net/mvc。