概念上的 MVC 格局被描述为多个指标 ——

   
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
卡塔尔国和视图模型(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”卡塔尔,就算对当下版本的世界模型做了金科玉律的印证,领域模型现在讲不定做了改观改良,并未现身编译错误或然警报,只怕引致新的风险。
   
咱俩应当防止采纳前二种方法将世界模型调换到视图模型,推荐应用第三种办法,定义单独的视图模型类。做这种领域模型到视图模型的转移工作是黄金时代种重复性的劳作,已经有多少个工具得以协助您来产生那项职业。最常用的三个工具就是.NET
社区的开源项目AutoMapper。

 (私家驾驭:针对域模型与视图模型,不常候供给看现实的政工场景,平时情状下得以依据上述将DomainModel和ViewModel实行多少映射,以幸免某个安全性难点;不过也足以将DomainModel当成ViewModel来行使也是可以的,通过在系统得以完结、业务逻辑操作和决断上是能够保障职业安全性的。正是后面一个也要举办判定以有限支撑安全性。所以,照旧看现实事务类别的接收条件与须要来调节使用哪一类方法来完结。

 

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

相关文章