UI(表现层): 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic。
DAL:(数据访问层): 与数据打交道。主要实现对数据的增、删、改、查。将存储的数据提交给业务层，同时将业务层处理的数据保存(数据库或者文本文件等存放数据的形式)。
Entity(实体):为了实现三层之间的数据流通，采用实体将数据的多种属性进行封装。
分层架构设计原则
在设计分层架构系统，需要考虑一下几种设计原则。
单一抽象层次原则
在进行分层时，我们还应该保证同一层的组件处于同一个抽象层次。每层完成独立的功能，层内部继续细分子模块，每层能够独立演进、部署。
分层原则可以基于业务抽象、硬件、变化性等来划分。
向下依赖设计
层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。
如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。
各层的功能基于同层和底层的功能之上，也就是说上层只能调用本层和下层的接口（实际设计中不建议基于跨层功能）。这样的设计避免互相调用导致的结构复杂。
在三层架构中，操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户。
松散分层系统（Relaxed Layered System）
是否允许跨层调用，即每一层都可以使用比它低的所有层的服务，而不仅仅是相邻低层。这就是所谓的“松散分层系统（Relaxed Layered System）”。
对于更底层的实体来说，一般会被多个上层实体，UI层调用。为了实现底层对上层的隔离，底层的实体，一般在调用该实体的最上层一个进行构建。
依赖倒置原则
依赖倒置原则（Dependency Inversion Principle，DIP）提出了对这种自顶向下依赖的挑战，它要求“高层模块不应该依赖于低层模块，二者都应该依赖于抽象”。
这一原则实际是“面向接口设计”原则的体现，即“针对接口编程，而不是针对实现编程”。各层提供相应的接口与实现分离，对该层的访问只能通过接口进行。通过接口进行访问有效的分离了关注点。外层关注接口，层内部关注接口的实现，实现的修改不会对其它层产生影响。
实际应用中可以使用适配器模式来有效的分离接口和实现。
观察者模式
层之间的协作并不一定是自顶向下的传递通信，也有可能是自底向上通信，观察者模式实现底层向上层消息的传递。当底层状态发生变化是，将变换的状态通知到上层进行更新。
在QT，使用信号与槽很好地实现了观察者模式。
