加深对于 MVC、MVP、MVVM 的概念理解
目录
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] 视图模型可以实现，组织对视图所支持的集的后端逻辑的访问。
viewmodel 作为中介者，屏蔽了数据绑定过程代码和gui代码，借助 xmal 标记语言可以轻松完成复杂的 gui 展示。wpf 的强大不用多说。
在此推荐两个按照 mvvm开发模式的开源项目