概述
MVC，即 Model 模型、View 视图，及 Controller 控制器。
- View：视图，为用户提供使用界面，与用户直接进行交互。
- Model：模型，承载数据，并对用户提交请求进行计算的模块。其分为两类，一类称为数据承载 Bean，一类称为业务处理 Bean。所谓数据承载 Bean 是指实体类，专门用户承载业务数据的，如 Student、User 等。而业务处理 Bean 则是指 Service 或 Dao 对象， 专门用于处理用户提交请求的。
- Controller：控制器，用于将用户请求转发给相应的 Model 进行处理，并根据 Model 的计算结果向用户提供相应响应。
MVC 架构程序的工作流程
- 用户通过 View 页面向服务端提出请求，可以是表单请求、超链接请求、AJAX 请求等
- 服务端 Controller 控制器接收到请求后对请求进行解析，找到相应的 Model 对用户请求进行处理
- Model 处理后，将处理结果再交给 Controller
- Controller 在接到处理结果后，根据处理结果找到要作为向客户端发回的响应 View 页面。页面经渲染（数据填充）后，再发送给客户端。
三层架构 + MVC 示意图
PS : MVC模式是三层架构的视图层
说说你对设计原则的理解
口诀
为了便于记忆,我们可以使用一一个几决来记忆面向对象设计原则:开口合里最单依
开:开闭原则
口:接口隔离原则
合:组合/聚合原则
里:里式替换原则
最:最少知识原则(迪米特法则)
单:单一职责原则
依:依赖倒置原则
开闭原则(Open-Closed Principle, 0CP)
一个软件实体应当刘扩展开发，对修改关闭说的是，再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展换言之，应当可以在不必修改源代码的情况下改变这个模块的行为,在保持系统定稳定性的基础F ,对系统进行扩展。这是面向对象设计( 0OD )的基石，也是最重要的原则。
接口隔离原则(Interface Segregation Principle, ISP)
一个类对另外一个类的依赖是建立在最小的接山上。
使用多个专J的接口比使用单-的总接C要好根据客户需要的不同，而为不同的客户端提供不同的服务是一 种应当得到鼓励的做法。就像”看人下菜碟”一 -样要看客人是谁，再提供不同档次的饭菜.
胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系当一个客户程序要求该胖接口进行-一个改动时,会影响到所有其他的客户程序,因此客户程序应该仅仅依赖他们实际需要调用的方法.
组合/聚合复用原则(Composite/Aggregate Reuse Principle , CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.
里氏代换原则(Liskov Substitution Principle，LSP)
说说你对设计原则的理解
口诀
为了便于记忆,我们可以使用一一个几决来记忆面向对象设计原则:开口合里最单依
- 开:开闭原则
- 口:接口隔离原则
- 合:组合/聚合原则
- 里:里式替换原则
- 最:最少知识原则(迪米特法则)
- 单:单一职责原则
- 依:依赖倒置原则
开闭原则(Open-Closed Principle, 0CP)
一个软件实体应当刘扩展开发，对修改关闭说的是，再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展换言之，应当可以在不必修改源代码的情况下改变这个模块的行为,在保持系统定稳定性的基础F ,对系统进行扩展。这是面向对象设计( 0OD )的基石，也是最重要的原则。
接口隔离原则(Interface Segregation Principle, ISP)
一个类对另外一个类的依赖是建立在最小的接山上。
使用多个专J的接口比使用单-的总接C要好根据客户需要的不同，而为不同的客户端提供不同的服务是一 种应当得到鼓励的做法。就像”看人下菜碟”一 -样要看客人是谁，再提供不同档次的饭菜.
胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系当一个客户程序要求该胖接口进行-一个改动时,会影响到所有其他的客户程序,因此客户程序应该仅仅依赖他们实际需要调用的方法.
组合/聚合复用原则(Composite/Aggregate Reuse Principle , CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.
里氏代换原则(Liskov Substitution Principle，LSP)
由 Barbar Liskov (芭芭拉.里氏) 提出，是继承复用的基石。
所有引用基类的地方必须透明的使用其子类的对象。只要父类能出现的地方子类也可以出现，而且替换为子类不会产生任何错误或异常，但是反过来就不行，有子类出现的地方，父类未必就能适应。
最少知识原则(Least Knowledge Principle，LKP)
一个对象应当对其他对象有尽可能少的了解.
没有任何一个其他的 OO 设计原则象迪米特法则这样有如此之多的表述方式,如下几种：
- 只与你直接的朋友们通信(Only talk to your immediate friends)
- 不要跟”陌生人”说话(Don’t talk to strangers)
- 每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位
就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
单一职责原则(Simple responsibility pinciple，SRP)
就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责.
依赖倒置原则(Dependence Inversion Principle)
要求客户端依赖于抽象耦合.
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过- 接口或抽象类产生的。
- 接口或抽象类不依赖实现类
- 实现类依赖接口或抽象类
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定，降低并行开发引起的风险，提高代码的可读性和可维护性。
