三层架构(UI、BLL、DAL)
目录
通常意义上的三层架构是指:
表示层 / 表现层 / (用户)界面层(UI:User Interface layer)
业务逻辑层 / 应用程序层 / 领域层(BLL:Business Logic Layer)
数据访问层 / 数据层 / 持久层(DAL:Data access layer)
表示层 / 表现层 / (用户)界面层 UI
主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
为客户端提供应用程序的访问。
UI层不只是一个个用户界面,也需要代码。
没有涉及到业务逻辑,直接传参、函数、方法调用,没有涉及到与数据库打交道的SQL语句和ADO.net。
业务逻辑层 / 应用程序层 / 领域层BLL
承上启下,UI层和DAL层之间的桥梁,对于一个支持可扩展的架构尤为关键。
对数据访问层而言是调用者,对表示层来说是被调用者。
负责数据处理、传递。
实现业务逻辑。
业务逻辑具体包含:验证、计算、业务规则等等。
没有涉及到界面控件,没有涉及到业务逻辑;只有与数据库打交道的SQL语句和ADO.net
数据访问层 / 数据层 / 持久层DAL
该层所做事务直接操作数据库,针对数据的增添、删除、修改、查找等。
将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。
三层框架之间的关系
用户的需求反映给UI,UI反映给BLL,BLL反映给DAL,DAL进行数据的操作,操作后再一一返回,直到将用户所需数据反馈给用户。
实体层 / 数据库实体类Entity
对数据对象进行封装,也有一些简单的功能。
不属于三层架构,但必不可少。
作为一个类库,起到封装数据库的作用。
贯穿三层之间,在三层之间传递数据。
三层架构的优势
1,结构清晰、耦合度低,符合“高内聚低耦合”的思想
2,可维护性高,可扩展性高
3,利于开发任务同步进行, 容易适应需求变化
三层架构的劣势
1、降低了系统的性能。
如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了代码量,增加了工作量,增加了访问成本。
相关文章
- javascript substr截取字符串
- 引入RabbitMQ后,你如何保证全链路数据100%不丢失?
- MySQL 定时备份数据库(非常全),值得收藏!
- 如何批量制作奇数流水号条形码
- TDSQL演进与突破:把企业级分布式数据库做到极致
- 《这么多MergeTree 表引擎,我该怎么选?》- part 2
- access怎样连接eclipse
- 全新池化方法AdaPool | 让ResNet、DenseNet、ResNeXt等在所有下游任务轻松涨点
- 为什么从 MongoDB 转向 Couchbase ?
- 全新数据增强 | TransMix 超越Mix-up、Cut-mix方法让模型更加鲁棒、精度更高
- Xcode控制台输出json数据乱码转为中文
- 怎么用jupyter导入数据集
- 两个小模型就能吊打大模型!北大校友、谷歌华人一作「模型集合」,CNN、Transformer都适用!
- [译]《iOS Human Interface Guidelines》——Table View表视图
- OushuDB 数据库基本用法 (上)
- 小课堂|计算文件Checksum的几种方法
- OushuDB 数据库基本用法(中)
- 分布式锁用Redis还是Zookeeper
- mmap详解
- pycharm数据库乱码怎么解决