三层架构

三层架构

三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。

View 层

视图层 负责和用户交互

用于输入输出和用户交互

Ui为Java控制台:

system.out.println(“”)打印输出

Scanner键盘输入

 

Service层

业务逻辑层:负责处理逻辑

接收视图层传来的参数,进行相应包装,传入dao层与数据库交互,

接收dao层返回(结果集,实体对象等)进行相应的逻辑处理判断,并将判断结果返回给view层

 

Dao层:

数据访问操作层 负责和数据库交互

 

 

 

例：登陆功能

 

问题：service层需要调用dao层成员方法，那么就需要新建一个dao层对象才能调用，如果业务逻辑在后来发生变化，更换成调用另一个dao层的方法，那么重新修改代码就很麻烦

此处复习依赖关系的概念：

  指的是一个类A使用到了另一个类B

  这种关系具有偶然性、临时性、非常弱的

  但是B类的改变会影响到A

  举例：人要过河，要借助船

  在代码层面,类B作为参数在A的某个方法中使用

处理方法:为了减少依赖关系,对service层,dao层各建立接口,使得实现类依赖于接口,遵循依赖倒转原则

依赖倒转原则

  高层模块不应该依赖于底层模块,二者都应该依赖其抽象

  抽象不应该依赖于细节,细节应该依赖于抽象

  类A直接依赖于类B,假如未来有可能改成类A依赖于类C,这种场景下

  类A就是高层模块,负责复杂的业务逻辑;

  类B和类C是低层模块,负责基本的原子操作

 * 面向对象 -> 面向接口

例:service层中的dao层成员属性:

View层中的service层成员属性:

 

Mvc与三层架构的区别

Mvc模式

他们是两个毫无相关的东西，经典三层架构是一种分层思想，将开发模式分为了这三层，每个人根据自己的专长，开发不同的模块，比如，前端工程师，那么就专研表示层即可，想办法如何让页面变的更好看，如何吸引别人，而有些专门做数据库工作的人，就可以只关注操作数据库的活，如何让查询更加快速有效，而不必关注数据该如何显示这种问题。这就是分层带来的巨大好处。

而MVC是一种设计模式，目的是让HTML代码和业务逻辑代码分开，让代码看起来更加清晰，便于开发。

硬说他们有关系的话，只能说他们有共同的点，分层，解耦。