MVC
MVC - 维基百科,自由的百科全书
MVC 是软件工程的一种软件架构模式,它不是具体的技术,而是一种代码分层的理念,主要体现了职责分离原则。
M-Model 模型
V-View 视图
C-Controller 控制器
对 MVC 的误解及缘由
误解:页面视图 = View ,Entity 和 Dto = Model
缘由:因为刚入坑程序员职业的时候,接触的是 ASP.NET Web Form 项目,而 ASP.NET Web Form 对于 Controller 和 View 的职责并没有很好的规划和定义,所以自己就很粗暴的把页面视图认为是 View 层。View 页面散列在各个 Controller 之下,虽竭力将文件夹命名清晰,但因为 Model 没有很好的实现,Dto乱飞,数据访问代码在 Controller 随处可见,某些 Controller 文件中代码堆积,各种逻辑全在 Controller 层。
尝试优化:将 View 归置到一个文件夹之下,将 Entity 和 Dto 独立类库,分出数据访问层 DataAccess 和 业务逻辑层 Business ,通用方法层 Common
项目结构大概是
- Demo.Web
- Views
- Controllers
- Demo.Entity
- Demo.Dto
- Demo.DataAccess
- Demo.Business
- Demo.Common
不太完美的结果:优化之后代码结构比之前的要清晰许多,Controller 放数据绑定代码和对参数的XSS校验和Sql注入校验。但是新的问题出现,数据库字段变动或者业务调整,Model 层的改动涉及到了 Entity、Dto、DataAccess、Business。在此不作 ASP.NET Web Form 和 ASP.NET MVC 的优劣比对。
MVP
MVP 是 MVC 模式的延伸,不是替代品。
P:Presenter
Presenter 包含着组件的事件处理,负责检索 Model 获取数据,和将获取的数据经过格式转换与 View 进行沟通。
摘自 Model-view-presenter - 维基百科,自由的百科全书
在我看来 Presenter 层应该是被包含在 Business 层,因为规划时对 Business 层的部分职责预想和上述引用完全一致。因为没有更具体地规划 Presenter ,所以后期项目中 Business 层和 Controller 层中参杂了本应由 Presenter 层承担的职责代码,降低了项目的可维护性。
MVVM
MVVM有助于将图形用户界面的开发与业务逻辑或后端逻辑(数据模型)的开发分离开来,这是通过置标语言或GUI代码实现的。MVVM的视图模型是一个值转换器,[1] 这意味着视图模型负责从模型中暴露(转换)数据对象,以便轻松管理和呈现对象。在这方面,视图模型比视图做得更多,并且处理大部分视图的显示逻辑。[1] 视图模型可以实现中介者模式,组织对视图所支持的用例集的后端逻辑的访问。
摘自 MVVM - 维基百科,自由的百科全书
ViewModel 作为中介者,屏蔽了数据绑定过程代码和GUI代码,借助 XMAL 标记语言可以轻松完成复杂的 GUI 展示。WPF 的强大不用多说。
在此推荐两个按照 MVVM开发模式的开源项目
- riganti/dotvvm: Open source MVVM framework for Web Apps
- dotnetcore/WTM: WTM框架是针对中小规模后台管理系统的开发利器。基于DotNetCore,实现0编码创建项目,0编码生成业务模块。框架严格遵循MVVM的开发模式,并深得MVVM的精髓。对于新手,可以快速上手搭建项目;对于高手,可以把那些繁琐重复的工作交给框架生成,专心攻克需求难点。框架经过数十个真实项目检测,可以极大提高开发效率,降低开发成本。