从传统的Web应用程序架构方法（包括业务层，服务层，数据访问层和表示层）转向MVC设计模式，我发现很难理解它如何适应旧模型 .
似乎MVC模型本身已经完成了分离关注点的分离，这些问题需要通过分层架构来实现 . 有人可以对这个问题有所了解吗？
As a reference, below is how I understand it, please share your view on this
MVC视图和控制器以及视图模型 - 表示层
MVC模型 - 可以是 - 数据访问层或业务层甚至服务层
我认为 Asp.Net MVC part 仅作为整个应用程序的 view (or presentation) part .
我也在努力解决如何以适当的方式构建应用程序的问题 .在 Onion Architecture 之后我听说 here （尤其是找到的图像here），我的解决方案看起来像这样：
Project.Core业务逻辑/服务实现，实体，接口必须由其他项目实现（即"IRepository"，"IAuthenticationService"，...）
Project.Data数据库连接 - 在我看来，NHibernate存储库和实体映射都在这里 . 实现Project.Core的数据接口
Project.UI.WebAsp.Net MVC（"presentation"）项目 - 它将整个应用程序连接在一起 .在Project.Core中实现接口的实现，并将它们（以及来自Project.Data的那些）连接到像Castle Windsor这样的DI框架 .
Project.UI.Web遵循以下约定：
其 models 仅为（！） viewmodels
views 消耗他们的 own viewmodel （one-view-one-viewmodel）
controllers 只需输入 validate ，将其转化为 domain objects （作为业务逻辑 knows exacly nothing about viewmodels ）和 delegate 实际工作（业务逻辑）到业务服务 .
Summary:如果您遵循此模型，则对 focus on Project.Core 有帮助： that 是 real application . 它没有't worry about the real persistence of data nor cares about how does it get presented. It'只是"how-to-do-it" . 但它正在规划其他项目必须提供实施的规则和 Contract （接口） .
我希望这可以帮助您如何布局Asp.Net MVC应用程序！
LGwarappa
正如其他人所说，它没有太大变化 . 我的应用程序通常是这样构建的：
模型层（域和视图模型）
存储库层（数据访问）
服务层（有时根据应用程序/要求实现为WCF服务）
服务器端MVC层（Asp.net MVC本身）
客户端MVVM或MVC（通过Knockout.js，Backbone.js或Spine.js）
在服务器端MVC层，我的控制器方法非常轻 . 他们通常在服务层对象上调用一个方法来获取一些数据，并将其作为Json数据传递给客户端 .
因为我要把Json送回去，我的观点也非常轻盈和稀疏 . 通常只包含脚本包含和将使用客户端模板库呈现的模板 .
简而言之：没有太大变化 .
我只熟悉一些演示模式：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操作的服务/业务层混合（因为数据访问既不属于视图模型也不属于控制器，绝对不属于视图！） .
非常基本的解释：
如果您创建一个新的MVC应用程序，您将自动获得一个Controllers，Models和Views文件夹 .
您的控制器就像您的业务层一样模型是数据访问/服务层和视图是表示层 .
有关详细说明，请参阅http://www.asp.net/mvc .
4 回答
我认为 Asp.Net MVC part 仅作为整个应用程序的 view (or presentation) part .
我也在努力解决如何以适当的方式构建应用程序的问题 .
在 Onion Architecture 之后我听说 here （尤其是找到的图像here），我的解决方案看起来像这样：
Project.Core
业务逻辑/服务实现，实体，接口必须由其他项目实现（即"IRepository"，"IAuthenticationService"，...）
Project.Data
数据库连接 - 在我看来，NHibernate存储库和实体映射都在这里 . 实现Project.Core的数据接口
Project.UI.Web
Asp.Net MVC（"presentation"）项目 - 它将整个应用程序连接在一起 .
在Project.Core中实现接口的实现，并将它们（以及来自Project.Data的那些）连接到像Castle Windsor这样的DI框架 .
Project.UI.Web遵循以下约定：
其 models 仅为（！） viewmodels
views 消耗他们的 own viewmodel （one-view-one-viewmodel）
controllers 只需输入 validate ，将其转化为 domain objects （作为业务逻辑 knows exacly nothing about viewmodels ）和 delegate 实际工作（业务逻辑）到业务服务 .
Summary:
如果您遵循此模型，则对 focus on Project.Core 有帮助： that 是 real application . 它没有't worry about the real persistence of data nor cares about how does it get presented. It'只是"how-to-do-it" . 但它正在规划其他项目必须提供实施的规则和 Contract （接口） .
我希望这可以帮助您如何布局Asp.Net MVC应用程序！
LG
warappa
正如其他人所说，它没有太大变化 . 我的应用程序通常是这样构建的：
模型层（域和视图模型）
存储库层（数据访问）
服务层（有时根据应用程序/要求实现为WCF服务）
服务器端MVC层（Asp.net MVC本身）
客户端MVVM或MVC（通过Knockout.js，Backbone.js或Spine.js）
在服务器端MVC层，我的控制器方法非常轻 . 他们通常在服务层对象上调用一个方法来获取一些数据，并将其作为Json数据传递给客户端 .
因为我要把Json送回去，我的观点也非常轻盈和稀疏 . 通常只包含脚本包含和将使用客户端模板库呈现的模板 .
简而言之：没有太大变化 .
我只熟悉一些演示模式：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操作的服务/业务层混合（因为数据访问既不属于视图模型也不属于控制器，绝对不属于视图！） .
非常基本的解释：
如果您创建一个新的MVC应用程序，您将自动获得一个Controllers，Models和Views文件夹 .
您的控制器就像您的业务层一样
模型是数据访问/服务层
和视图是表示层 .
有关详细说明，请参阅http://www.asp.net/mvc .