2011-05-13 119 views
15

从传统的将业务层,服务层,数据访问层和表示层构建到Web应用程序的方式转变为MVC设计模式,我觉得很困难了解它如何适应旧模式。ASP .NET MVC体系结构适合传统的多层体系结构

似乎MVC模型本身已经完成了需要分离的问题,而这些问题是通过分层体系结构来实现的。请问有人可以在这个问题上谈一谈?

作为参考,下面是我的理解它,请在此

MVC的视图和控制器与视图模型-are- 表示层

MVC模型一起分享你的观点 - 能是 - 数据访问层或业务层甚至业务层

+1

可能重复[如何MVC(ASP.NET MVC)带3层架构可以一起工作?](http://stackoverflow.com/questions/3047230/how-mvc- asp-net-mvc-band-3-tier-architecture-can-work-together) – jgauffin 2011-05-13 11:17:50

+2

这不是重复的,因为另一篇文章讨论的三层体系结构更多地来自物理的分离视角而不是概念上的分离。 – Max 2011-05-13 15:12:17

回答

36

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

我也在努力解决如何以适当的方式构建应用程序的问题。
洋葱架构我听说here(尤其是图像中发现here),我的解决方案看起来是这样的:

  • 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
  • 意见消耗他们自己的视图模型(单view-one-viewmodel)
  • the controllers just nee d到验证输入,转换域对象(如业务逻辑exacly一无所知的ViewModels)和代表实际工作(业务逻辑)的业务服务。

摘要:
如果按照这个模型是有帮助的重点项目。Corereal应用。它不担心数据的真实持久性,也不关心它如何呈现。这只是关于“如何做”。但它规定了其他项目必须提供实现的规则和契约(接口)。

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

了Lg
warappa

+1

我不明白核心服务实现是如何实现的。它不应该超出Project.Core的范围吗?这样,你可以防止意外紧密耦合到svc而不是svc接口。 – Narayana 2013-12-10 07:50:11

-2

非常基本的解释:

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

您的控制器的行为与您的业务层类似
模型是数据访问/服务层
和视图是表示层。

有关详细解释,请参见http://www.asp.net/mvc

+14

控制器不是业务层。事实上,控制器应尽可能薄 – psousa 2011-05-13 11:12:40

+2

我与@psousa在这一个,事实上,微软建议在控制器中根本没有任何业务逻辑,并处理所有模型。 – Max 2011-05-13 15:16:46

0

总之:没有太大的变化。我只熟悉一些演示模式: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操作的服务/业务层混合(因为数据访问既不属于视图模型也不属于控制器,绝对不属于视图!)。

+0

如果你使用enitiy框架怎么办?它确实以一套简单管理的MVC数据模型的形式为您提供抽象。你需要一个附加的数据访问层吗? – Max 2011-05-13 15:22:46

+0

像Automapper这样的东西可以用来将EF的实体映射到您的域模型。我建议将域模型保留在MVC模型名称空间之外,并将它们放入它们自己的程序集中。 – 2011-05-13 17:12:05

3

正如其他人所说,它并没有太大的变化。我的应用程序通常是架构这样:

  • 模型层(域和视图模型)
  • 库层(数据访问)取决于 应用程序/要求
  • 服务层(有时实施 为WCF服务)
  • 服务器侧MVC 层(Asp.net MVC本身)
  • 客户端侧MVVM或MVC(经由 任Knockout.js,Backbone.js的,或 脊柱。js)

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

因为我送Json回来,所以我的看法也非常轻而稀疏。通常只包含脚本包含和将用客户端模板库呈现的模板。