三层架构含义:
UI(表现层) User Interface layer: 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
BLL:(业务逻辑层) Business Logic Layer: UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含:验证、计算、业务规则等等。
DAL:(数据访问层) Data access layer: 与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。(当然这些操作都是基于UI层的。用户的需求反映给界面(UI),UI反映给BLL,BLL反映给DAL,DAL进行数据的操作,操作后再一一返回,直到将用户所需数据反馈给用户)
服务员相当于UI,接受顾客的菜品需求,并传达给厨师
厨师相当于BLL,接收到服务员提供顾客所需的菜品,就必须去进行加工处理,那么必然需要找采购员询问,是否有这种食材。
采购员将厨师需要的菜品,到市场中去采购,匹配采购单。然后将买到的菜给厨师。
那怎么将三者连接起来呢?实体类成为了关键。
Entity(实体类)
我们先来看看其作用
-
1、实现面向对象思想中的"封装";
-
2、贯穿于三层,在三层之间传递数据;(注:确切的说实体层贯穿于三层之间,来连接三层)
-
3、对于初学者来说,可以这样理解:每张数据表对应一个实体,即每个数据表中的字段对应实体中的属性(注:当然,事实上不是这样。为什么?1>,可能我们需要的实体在数据表对应的实体中并不存在;2>,我们完全可以将所有数据表中的所有字段都放在一个实体里)
-
4、每一层(UI—>BLL—>DAL)之间的数据传递(单向)是靠变量或实体作为参数来传递的,这样就构造了三层之间的联系,完成了功能的实现。
那为什么不直接端上方便食品呢?方便又快捷
下面讲讲述三层架构的优缺点
三层架构的优点:
-
1,结构清晰、耦合度低(主要目的)
-
2,可维护性高,可扩展性高
-
3,利于开发任务同步进行, 容易适应需求变化
三层架构缺点:
-
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
-
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
-
3、增加了代码量,增加了工作量
不过使用了三层架构肯定是好处大于弊端的,要不然你就不会学了。