葡京会Model从表现层分离领域模型,领域模型

   
Model-View-Controller(模型-视图-控制器,MVC)格局将您的软件协会并分解成三个完全不一样的剧中人物:

Model-View-Controller(模型-视图-控制器,MVC)
情势将你的软件协会并分解成八个精光不一样的角色:

  • Model
    封装了你的施用数据、应用流程和作业逻辑。
  • View
    从 Model 获取数据并格式化数据以开始展览体现。
  • Controller
    控制造进程序流程,接收输入,并把它们传递给 Model 和 View。
  • Model 封装了您的运用数据、应用流程和工作逻辑。

  • View 从 Model 获取数据并格式化数据以开始展览体现。

  • Controller 控制造进程序流程,接收输入,并把它们传递给 Model 和 View。

   
与别的设计形式差别,MVC
方式并从未直接呈现3个你可见编写或陈设的类组织。相反,MVC
更像一个定义上的引导规范或范型。概念上的 MVC 方式被描述为多个对象 ——
Model、View 和 Controller —— 之间的涉嫌。由于 View 和 Controller
都得以从 Model 请求数据,所以 Controller 和 View 都凭借
Model。任何输入都通过 Controller 进入你的种类,然后 Controller 选拔二个View 来爆发结果。

与其余设计格局不一致,MVC
形式并未有直接展示多个你能够编写或配备的类组织。相反,MVC
更像贰个定义上的点拨原则或范型。概念上的 MVC 模式被描述为几个目的 ——
Model、View 和 Controller —— 之间的关系。由于 View 和 Controller
都足以从 Model 请求数据,所以 Controller 和 View 都依靠
Model。任何输入都通过 Controller 进入你的类别,然后 Controller 选取2个View 来发出结果。

    Model
包罗了您的应用逻辑和多少,在你的应用程序中,它很或者是首要的值驱动器。Model
未有任何与表现层相关的特色,而且也和 HTTP
请求处理职务中全然毫不相关。

Model
包涵了你的应用逻辑和数目,在你的应用程序中,它很或然是生死攸关的值驱动器。Model
未有其它与表现层相关的风味,而且也和 HTTP 请求处理职责中全然毫不相关。

    Domain
Model
是三个指标层,是对具体世界逻辑、数据和你应用程序所拍卖的标题标虚幻。

Domain Model
是三个对象层,是对现实世界逻辑、数据和您应用程序所拍卖的题材的架空。Domain
Model 可分为两大类:Simple Domain Model 和 Rich Domain Model。

    Domain
Model 可分为两大类:Simple Domain Model 和 Rich Domain Model。

Simple Domain Model
往往是工作对象和数据库表之间1对1的通讯。你已经见过的二种格局 —— Active
Record、Table Data Gateway,以及 Data
Mapper,全数那一个与数据库相关的设计形式 ——
能够援救你把与数据库相关的逻辑组织成2个 Domain Model。

  • Simple Domain Model
    往往是工作对象和数据库表之间一对1的通信。你曾经见过的三种情势 ——
    Active Record、Table Data Gateway,以及 Data
    Mapper,全部那个与数据库相关的设计格局 ——
    能够援助你把与数据库相关的逻辑协会成一个 Domain
    Model。
  • Rich Domain
    Model 包蕴复杂的,使用持续机制紧凑联系在联合署名的靶子互联网,在本书和 GoF
    一书中介绍的不少形式起着杠杆作用。Rich Domain Models
    往往是柔性的,精心测试过的,不断重构的,而且与它们所发挥的圈子所需的工作逻辑严苛耦合。

Rich Domain Model
包罗复杂的,使用持续机制紧凑联系在联合署名的目的网络,在本书和 GoF
一书中牵线的累累形式起着杠杆作用。Rich Domain Models
往往是柔性的,精心测试过的,不断重构的,而且与它们所抒发的天地所需的事务逻辑严密耦合。

   
选择哪类 Domain
Model 类型取决于你的应用环境。假使您正在创立的是一个非凡简单的表单处理
web 应用,没要求建立 Rich Domain
Model。不过,倘诺您正在编写制定3个市场总值数百万的店堂内联网架构的基本库,那么拼命付出二个Rich Domain Model
便是值得的,它能够为你提供贰个纯粹表达业务进程的平台,并得以让您急速传输数据。

行使哪个种类 Domain Model
类型取决于你的应用环境。如若您正在成立的是一个格外简单的表单处理 web
应用,没要求建立 Rich Domain
Model。不过,借使您正在编纂二个股票总值数百万的小卖部内联网架构的主干库,那么拼命付出3个Rich Domain Model
正是值得的,它能够为您提供2个准确表明业务进度的阳台,并得以让您急忙传输数据。

    马丁Fowler 在 PoEAA 中而且省略介绍了二种 Domain Model。而 埃里克 埃文思 的
Domain Driven Design 1书,则一心专注于 Rich Domain Model
的执行应用和开发进程。

马丁 Fowler 在 PoEAA 中同时省略介绍了三种 Domain Model。而 埃里克 埃文思的 Domain Driven Design 一书,则完全专注于 Rich Domain Model
的履行应用和开支进度。

    View
用于拍卖全数表现层方面包车型大巴难题。View 从 Model
获取数据,并能够把它格式化成用于 web 页的 HTML,用于 web 服务的
XML,或用来 email 的文书。

View 用于拍卖全体表现层方面包车型地铁题材。View 从 Model
获取数据,并能够把它格式化成用于 web 页的 HTML,用于 web 服务的
XML,或用来 email 的文件。

   
许多的MVC格局的达成也都使用二个View Model或Application
Model的概念,Controller是维系的介绍人,架起世界模型和用户界面之间的桥梁,属于表现层。为了View的不难性,Controller负责处理也许将世界模型转换来四个View
Model,那平常号称数据传输对象(DTO)

洋洋的MVC格局的完结也都应用二个View Model或Application
Model的概念,Controller是关联的媒介,架起世界模型和用户界面之间的大桥,属于表现层。为了View的简单性,Controller负责处理也许将世界模型转换来二个View
Model,那平时号称数据传输对象(DTO)。

    DomainModel != ViewModel

<译>10个asp.net
MVC最佳实践
本着Model的一级实践有那样1段:

   
DomainModel代表着相应的域,但ViewModel却是为View的供给而成立。那两者之间或然(壹般景况下都)是见仁见智的,其它DomainModel是多少增进行为的组合体,是由复杂的变量类型组成的还要拥有层次。而ViewModel只是由一些String等简易变量类型组成。要是想移除冗余并且简单造成出错的OQashqaiM代码,能够采用AutoMapper.假如想要驾驭更加多。

7–DomainModel != ViewModel

 *DomainModel代表着相应的域,但ViewModel却是为View的急需而创办。那两者之间只怕(1般景观下都)是例外的,其它DomainModel是数码增加行为的组合体,是由复杂的变量类型组成的同时有着层次。而ViewModel只是由局部String等简便变量类型组成。假设想移除冗余并且不难导致出错的O猎豹CS6M代码,能够运用[AutoMapper](http://www.codeplex.com/AutoMapper).借使想要理解越来越多,作者推荐阅读:[ASP.NET
MVC View Model
Patterns](http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx).*

那么领域模型(Domain Model )和视图模型(View Model)有何分歧啊?

在ASP.NET MVC的应用程序中时时能够能够看看View
Model,平常大家都觉得世界模型和视图模型是同2个东西。那特别是把世界模型包蕴在数码传输对象DTO里的时候,例如利用Entity
Framework之类的OLX570M工具生成的实业。在那种气象下,领域模型和视图模型包涵的实业至极相像,都以有个别简单易行的CRUD操作。

那些实体有好多性子,有雷同或看似的称谓,你能够很不难地映射领域实体对应视图模型中的一本性能。但是,这一个相似的性格也说不定略有不一致,例如类型可能格式。例如,用户填写的用户界面包车型大巴2个属性,他在视图模型里大概是一个“Nullable”的。另1方面,领域实体大概须求三个通过证实的合法的值,所以须要2个在用户界面包车型地铁天地模型之间的转换。另3个例证是,用户界面大概会议及展览示叁个滑块,用于用户选取多少天之后提交他的订单。在那种情景下,视图模型大概选拔一个平头性格来代表,领域模型平时是一个日期值。

视图模型日常只含有领域模型的3个子集,而且只包罗界面上所须求的习性。其它,视图模型恐怕是一个天地模型树的扁平版本,例如,多个Customer实体有贰个Address,而那又是多少个全体,它富含街道地址,邮编,国家等。一个Customer
视图模型用于呈现数据,将地址数据拉平填充到视图模型类里。

别的假若三个View须要同时处理多少个世界模型,View Model便是这多少个Domain
Model的总和。领域模型和视图模型之间有过多1般的地方,大家常常干脆就把Domain
Model当作View Model来使用了。

上面研商了世界模型和视图模型的相似性,大家来看望都有三种艺术把世界模型转换为视图模型,平时有三种方式:

  1. 把世界模型当作视图模型来用,也正是世界模型正是视图模型,大多数都以那般用的。
  2. 视图模型里面包罗三个天地模型,定义1个视图模型,里面富含了二个世界模型,通过性能形式进行走访。
  3. 将世界模型映射到视图模型,领域模型并不曾一直照射到视图模型,须求处理那种映射关系。

笔者们不建议直接把世界模型实体揭发给视图,因为有无数微小之处,恐怕导致您混合业务和表示层的逻辑,无论是领域实体的属性呈现照旧政工的求证规则,那都以应用程序处理的例内地点。直接将你的世界模型作为Conroller上的拍卖参数面临着平安危机,因为Controller大概Model
binder必须保障属性验证和用户不可能修改她要好无法改改的属性(例如,用户手动更新了3个潜伏的输入值,或追加2个外加的属性值,而以此并不是界面上的因素,但却凑巧领域模型实体的习性,那种高风险叫做“over-posting”),尽管对现阶段版本的领域模型做了不错的评释,领域模型现在恐怕做了变更修改,并不曾现身编译错误也许警告,恐怕造成新的高风险。

我们相应防止采取前三种格局将世界模型转换到视图模型,推荐使用第三种方法,定义单独的视图模型类。做那种领域模型到视图模型的变换工作是一种重复性的行事,已经有多少个工具得以援救您来达成那项工作。最常用的一个工具正是.NET
社区的开源项目AutoMapper

 

如何行使AutoMapper能够参考上面包车型大巴两篇文章介绍:

AutoMapper Formatters are Cool – ASP.NET MVC
Style

AutoMapper in NerdDinner

   
那就是说领域模型(Domain Model
)和视图模型(View Model)有啥不一样吧?

   
在ASP.NET MVC的应用程序中时时能够可以看来View
Model,平常大家都觉着世界模型和视图模型是同多少个事物。那越发是把世界模型包括在数码传输对象DTO里的时候,例如使用Entity
Framework之类的O瑞鹰M工具生成的实业。在那种状态下,领域模型和视图模型包括的实体相当相似,都是部分粗略的CRUD操作。

   
这个实体有多如牛毛质量,有一样或近乎的名号,你能够很不难地映射领域实体对应视图模型中的一天性情。可是,那些相似的品质也大概略有差异,例如类型也许格式。例如,用户填写的用户界面包车型大巴二本性质,他在视图模型里大概是3个“Nullable”的。

   
另1方面,领域实体恐怕须求1个通过认证的官方的值,所以需求1个在用户界面包车型大巴圈子模型之间的转换。另多少个例子是,用户界面恐怕会议及展览示贰个滑块,用于用户选取多少天未来提交他的订单。在那种情景下,视图模型大概应用3个平头性情来代表,领域模型经常是二个日期值。

   
视图模型平常只蕴涵领域模型的3个子集,而且只含有界面上所供给的属性。其余,视图模型或者是1个世界模型树的扁平版本,例如,一个Customer实体有1个Address,而那又是四个完整,它含有街道地址,邮编,国家等。多个Customer
视图模型用于体现数据,将地方数据拉平填充到视图模型类里。

   
别的要是几个View必要同时处理多少个世界模型,View
Model就是那多少个Domain
Model的总额。领域模型和视图模型之间有很多1般的地点,大家平时干脆就把Domain
Model当作View Model来使用了。
   
上边研讨了世界模型和视图模型的相似性,大家来看望都有两种办法把世界模型转换为视图模型,平日有3种方式:

  • 把世界模型当作视图模型来用,也便是世界模型正是视图模型,超越57%都是那般用的。
  • 视图模型里面富含二个领域模型,定义三个视图模型,里面含有了2个天地模型,通过质量形式展开走访。
  • 将世界模型映射到视图模型,领域模型并未一直照射到视图模型,须求处理那种映射关系。

   
大家不提议直接把世界模型实体暴光给视图,因为有过多轻微之处,大概引致你混合业务和表示层的逻辑,无论是领域实体的习性显示依旧政工的证实规则,那都以应用程序处理的不比方面。

   
直接将你的园地模型作为Conroller上的处理参数面临着安全危机,因为Controller恐怕Model
binder必须保险属性验证和用户不能够改改她自个儿不可能修改的品质(例如,用户手动更新了贰个隐蔽的输入值,或充实3个相当的属性值,而那一个并不是界面上的成分,但却刚好领域模型实体的性格,那种风险叫做“over-posting”),即使对脚下版本的小圈子模型做了天经地义的印证,领域模型今后恐怕做了改变修改,并未出现编写翻译错误或然警示,大概引致新的危害。
   
我们应当制止选拔前二种格局将世界模型转换到视图模型,推荐使用第3种方法,定义单独的视图模型类。做这种领域模型到视图模型的变换工作是1种重复性的行事,已经有多少个工具得以援救您来达成那项工作。最常用的二个工具就是.NET
社区的开源项目AutoMapper。

 (民用精通:针对域模型与视图模型,有时候要求看现实的事务场景,1般情状下得以依照上述将DomainModel和ViewModel进行数据映射,以免止有个别安全性难点;但是也能够将DomainModel当成ViewModel来使用也是能够的,通过在系统贯彻、业务逻辑操作和判断上是足以保障工作安全性的。正是前者也要开始展览判定以保证安全性。所以,依旧看现实业务系统的施用环境与供给来支配运用哪一种办法来落到实处。

 

小说转发自:http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html

相关文章

admin

网站地图xml地图