三层架构

三层架构

a) 解释
显示层 ：只做显示相关的处理
业务逻辑层：业务处理 业务层之间的函数不互相调用
数据库访问层：操作数据库

b) 分包
视图层
com.hpe.view 用户界面
业务逻辑层
com.hpe.service
数据持久层
com.hpe.dao 数据库访问
其它
com.hpe.po 实体类
com.hpe.vo 视图类（联表查询实体类）
工具类
com.hpe.util

c) 优点
开发人员可以只关注整个结构中的其中某一层；
可以很容易的用新的实现来替换原有层次的实现；
可以降低层与层之间的依赖；
有利于标准化；
利于各层逻辑的复用。
结构更加的明确
在后期维护的时候，极大地降低了维护成本和维护时间

d) 缺点
降低了系统的性能。（如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成）
有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

e) 进一步理解
显示层，只做显示处理。通过调用业务层的方法获取返回值，根据对应的返回值做出相应的输出即可。不需要做太多的处理
业务层：本层中定义的方法要对应程序的功能点，即一个功能点封装成一个方法，对于方法的返回值要尽可能的简单，便于显示层判断，做输出处理，对于参数也要尽可能地简单；另外业务层之间的方法不可以互相调用，其功能实现只能借助于数据库连接层方法，对于事物要在业务层处理，但本层不直接操作数据库
数据库连接层：该层中的方法只需要对SQL语句进行处理，不需要做太多的处理，关于事务的操作一定要放在业务层处理

f) 三层架构中，同层之间的方法是不互相调用的，只能由显示层调用业务层，业务层做出处理并将返回值返回，显示层对不同的返回值做出不同的处理。业务层调用数据库连接层的方法，实现对数据库的增删改查，关于事务的操作不需要在数据库连接层处理，事务需要的业务层通过工具类处理。业务层中不能直接操作数据库