最早学编程的时候看过一些书，印象深刻的一本书《设计模式解析》，那本书给我后来的工作提供了很大的帮助。
他叫我站在问题模型的立场上指定解决方法，也教会了我软件设计中每个问题都可以细化到到不可再分割的原子性。
在那书以后看到过一些设计模式的书出现。由于本人比较崇尚于权威或者说正统性的学术性书籍，没怎么看其他本书。
最近一些年在网上看到过一些博客中把MVC说成设计模式，这个说法是错误的，MVC实际是软件架构模式。
笔者可以毫不客气的说，工作几年以后，有一些人说MVC是设计模式，基本上是滥竽充数的程序员。
因为mvc并没有设计模式中那种问题场景原型，他是一个软件架构的泛化思想模型，比如工厂模式他可以解决需求更新时频繁
维护方法代码，只要传入参数，他就给你对象，比如java中的用class.forname来装载类。
笔者读书不多，对于MVC的粗浅理解如下，供大家参考：
MVC是一种软件架构模式，他模拟人类社会分工，通过分工协作来完成一件事，完成这件事可能需要很多种工种，这里我们可以把
这些工作按角色来理解，理解成软件中的各个层。
比如一个工程项目，公司老板安排设计人员去做标书，标书做完投标，然后把工程转给技术部项目经理，项目经理安排技术人员去安装，
技术人员安装好以后反馈给项目经理，项目经理向老板汇报这个标已经完成，至此一个项目结束。
这个流程中：安排、转、汇报几个词语大概反应了一个完整项目中各个角色之间交互的特点，即任务调度及分发，以及
任务结果反馈。
一个项目中如果用到了mvc架构模式，不管项目大小，按群体/角色/职责分工大概有Model层，Controller层，View层。
Model可以理解为基层，做一些苦力，基础性的工作。
Controller可以理解为管理层，他们通常负责下发命令、调度任务
View层可以理解为用户界面及用户交互层。
我们刚刚举例的工程项目中：老板、项目经理他们是Controller层，一个是下发命令，一个调度任务
其中设计部角色 以及技术人员他们是Model层，他们是做基础工作的，他们这一层有一些粗糙的接口，可以和其他角色的人
来交流反馈任务结果。
篇博客临时有点想法，算是吐槽，关于View层笔者没有想到详细的描述方式。
在软件MVC架构中，我们的Model，View，Controller层大家都能划分清楚吧，网上教程很多。
笔者的理解是，不管项目中有没有MVC框架，合理的MVC框架设计应该遵循以下原则：
M层数据持久层，负责与数据库通信，这一层包含数据模型实体类，以及一些CRUD方法。
C层主要负责调度任务，得到V层需求下发命令，最多出现的应该是把任务转发给其他类处理。
例如
DataStoreBLL dbll = new DataStoreBLL();
dbll.doSave(Entity entity){
DataStoreDAL dbal = new DataStoreDAL();
dbal.doSave(entity);
}
实际数据持久化任务通过BLL转发给DAL来处理，BLL只得到处理结果。
C层不应该出现数据库操作代码，例如jdbc的getConnection
View层负责与用户交互，展示处理结果给用户看，可以是web ui，cui，gui，app ui等
各个层之间通信应依赖于抽象（接口或者抽象类）。
