都得以从 Model 恳求数据

   
Model-View-Controller(模型-视图-调节器,MVC卡塔 尔(英语:State of Qatar)情势将你的软件协会并分解成四个精光差别的剧中人物:

  • Model
    封装了你的施用数据、应用流程和事务逻辑。
  • View
    从 Model 获取数据并格式化数据以开展呈现。
  • Controller
    调控造进程序流程,接受输入,并把它们传递给 Model 和 View。

   
与别的设计形式差异,MVC
方式并从未一向反映二个您可见编写或安插的类协会。相反,MVC
更像四个概念上的点拨原则或范型。概念上的 MVC 方式被描述为八个对象 ——
Model、View 和 Controller —— 之间的涉嫌。由于 View 和 Controller
都足以从 Model 诉求数据,所以 Controller 和 View 都依赖Model。任何输入都通过 Controller 步向你的系统,然后 Controller 选拔叁个View 来发出结果。

    Model
包罗了您的应用逻辑和数目,在你的应用程序中,它很也许是第风流浪漫的值驱动器。Model
未有其它与表现层相关的特性,并且也和 HTTP
央求管理职务中全然非亲非故。

    Domain
Model
是一个指标层,是对切实世界逻辑、数据和您应用程序所处理的题材的架空。

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

  • Simple Domain Model
    往往是职业对象和数量库表之间意气风发对大器晚成的通讯。你曾经见过的三种形式 ——
    Active Record、Table Data Gateway,以致 Data
    Mapper,全数这个与数据库相关的设计格局 ——
    能够扶助你把与数据库相关的逻辑组织成多个 Domain
    Model。
  • Rich Domain
    Model 蕴含复杂的,使用持续机制紧凑联系在生龙活虎道的对象网络,在本书和 GoF
    豆蔻梢头书中牵线的看不尽形式起着杠杆成效。Rich Domain Models
    往往是柔性的,精心测验过的,不断重构的,並且与它们所发挥的圈子所需的政工逻辑严密耦合。

   
选择哪一类 Domain
Model 类型决计于你的应用情状。假设你正在创立的是七个特别轻巧的表单处理web 应用,没要求建构 Rich Domain
Model。可是,如若你正在编写制定八个市场总值数百万的集团内联网架构的中坚库,那么拼命付出二个Rich Domain Model
便是值得的,它可感到您提供一个正确表明业务进度的平台,并得以让您快捷传输数据。

    MartinFowler 在 PoEAA 中同一时间回顾介绍了二种 Domain Model。而 Eric 埃文思 的
Domain Driven Design 生机勃勃书,则完全静心于 Rich Domain Model
的实施应用和支付进程。

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

   
大多的MVC方式的兑现也都接收叁个View Model或Application
Model的概念,Controller是调换的红娘,架起世界模型和顾客分界面之间的大桥,归于表现层。为了View的简单性,Controller负担管理大概将世界模型转变到三个View
Model,那日常堪当数据传输对象(DTO卡塔 尔(阿拉伯语:قطر‎

    DomainModel != ViewModel

   
DomainModel代表着相应的域,但ViewModel却是为View的内需而创设。这两个之间只怕(常常景况下都)是莫衷一是的,其余DomainModel是数量增加行为的组合体,是由复杂的变量类型组成的还要有所档期的顺序。而ViewModel只是由局地String等简易变量类型组成。如若想移除冗余何况轻巧以致出错的ORM代码,能够动用AutoMapper.假诺想要领悟越多。

   
那就是说领域模型(Domain Model
卡塔 尔(英语:State of Qatar)和视图模型(View Model卡塔尔有何两样啊?

   
在ASP.NET MVC的应用程序中经常能够可以见见View
Model,平常我们都以为世界模型和视图模型是同一个事物。那非常是把世界模型蕴含在数额传输对象DTO里的时候,举例使用Entity
Framework之类的ORM工具生成的实业。在此种景况下,领域模型和视图模型富含的实业极其近似,都是部分简易的CRUD操作。

   
这一个实体有好多属性,有同等或周边的名目,你能够十分轻巧地映射领域实体对应视图模型中的四本性格。不过,这么些相同的属性也可以有可能略有不一样,比如类型恐怕格式。举个例子,顾客填写的客户分界面包车型地铁二个天性,他在视图模型里也许是三个“Nullable”的。

   
另一面,领域实体恐怕需求多少个经过验证的法定的值,所以须要四个在顾客分界面包车型地铁园地模型之间的调换。另叁个事例是,客商分界面或者博览会示四个滑块,用于客户筛选多少天之后提交他的订单。在这种地方下,视图模型可能使用二个整数属性来表示,领域模型经常是一个日期值。

   
视图模型常常只富含领域模型的一个子集,况兼只含有分界面上所急需的属性。别的,视图模型可能是二个天地模型树的扁平版本,比方,一个Customer实体有二个Address,而那又是叁个完整,它包罗街道地址,邮编,国家等。一个Customer
视图模型用于体现数据,将地点数据拉平填充到视图模型类里。

   
别的如若三个View需求相同的时间管理多少个世界模型,View
Model正是那多少个Domain
Model的总额。领域模型和视图模型之间有好些个相像的地点,我们平常干脆就把Domain
Model充当View Model来行使了。
   
下边斟酌了世界模型和视图模型的相同性,大家来探问都有二种办法把世界模型转变为视图模型,平日常有3种艺术:

  • 把世界模型当做视图模型来用,也便是世界模型正是视图模型,超越五塔林以那般用的。
  • 视图模型里面富含三个世界模型,定义叁个视图模型,里面包罗了三个领域模型,通过质量方式开展拜会。
  • 将世界模型映射到视图模型,领域模型并从未一直照射到视图模型,须求处理这种映射关系。

   
大家不建议直接把世界模型实体暴光给视图,因为有比比较多微薄之处,或然引致您混合业务和表示层的逻辑,无论是领域实体的质量凸显还是工作的认证准则,那都是应用程序管理的两样方面。

   
直接将你的天地模型作为Conroller上的管理参数直面着安全风险,因为Controller可能Model
binder必需保证属性验证和顾客不能改改她本人不能够改善的属性(比如,客商手动更新了一个藏身的输入值,或追加三个外加的属性值,而那些并不是分界面上的因素,但却恰巧领域模型实体的习性,这种危害叫做“over-posting”卡塔 尔(英语:State of Qatar),尽管对当前版本的圈子模型做了正确的证实,领域模型现在可能做了转移改善,并从未现身编写翻译错误只怕警报,恐怕导致新的风险。
   
笔者们理应制止使用前二种格局将世界模型调换到视图模型,推荐应用第二种方法,定义单独的视图模型类。做这种领域模型到视图模型的转换专门的学问是黄金年代种重复性的行事,已经有多少个工具得以辅助您来达成那项职业。最常用的三个工具正是.NET
社区的开源项目AutoMapper。

 (个人精通:针对域模型与视图模型,不常候要求看具体的专门的学业场景,日常景观下能够据守上述将DomainModel和ViewModel实行数量映射,防止止有个别安全性难点;不过也得以将DomainModel当成ViewModel来使用也是足以的,通过在系统得以达成、业务逻辑操作和决断上是能够保险工作安全性的。正是前面一个也要开展推断以确认保障卫安全全性。所以,照旧看现实事务种类的运用条件与须要来支配动用哪一种艺术来实现。

 

随笔转载自:http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html

相关文章