加深对于 MVC、MVP、MVVM 的概念理解

目录

• MVC
  • 对 MVC 的误解及缘由
• MVP
• MVVM

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的精髓。对于新手，可以快速上手搭建项目；对于高手，可以把那些繁琐重复的工作交给框架生成，专心攻克需求难点。框架经过数十个真实项目检测，可以极大提高开发效率，降低开发成本。