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