加深对于 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开发模式的开源项目
