Blog2-客户端架构
一.客户端架构简介
客户端(Client)或称为用户端,是指与服务器相对应,为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外,一般安装在普通的客户机上,需要与服务端互相配合运行。
架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口(计算机科学)来实现。
在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”
二.常见的架构方式
针对数据流动的方向而言,分为分层架构,MVC架构,MVVM架构,MVP架构。
1.分层
分层架构是一种常见的软件应用架构,在 Java 程序中可以算是一种应用标准了,通常又叫 N 层架构。
优点:
1、开发人员可以只关注整个结构中的其中某一层;
2、可以很容易的用新的实现来替换原有层次的实现;
3、可以降低层与层之间的依赖;
4、有利于标准化;
5、利于各层逻辑的复用。
缺点:
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
1.1三层架构
最常见的是 3 层架构,它从上至下包含如下 3 层:
展示层(Presentation tier),也称为 UI 层,也就是程序的界面部分。
业务层(business logic(domain) tier), 业务层,是最为核心的一层。
持久层(Data tier),数据持久层。
层次 |
作用 |
设计原则 |
表示层(UI) |
向用户展现特定业务数据,采集用户的输入信息和操作。 |
用户至上,兼顾简洁;不包含任何业务相关的逻辑处理。 |
业务逻辑层(BLL) |
从DAL中获取数据, 在UI显示; 从UI中获取用户指令和数据, 执行业务逻辑或通过DAL写入数据源。 |
作为U层与D层的桥梁,目的在于展现清晰的函数结构, 只负责数据处理传递, 不涉及SQL语句和ADO.NET。 |
数据访问层(DAL) |
直接操作数据库,针对数据的增添 删除 修改 查找; 具体为业务逻辑层或表示层提供数据服务。 |
专门操作数据库, 不考虑数据合法性. 数据库错误返回-1, 逻辑错误返回0, 并告知错误原因, 成功返回1 |
3 层架构是存在物理上分层概念的,从上往下即展示层、业务层、持久层,也从上往下由上一层依赖下一层。不同层之间也是高内聚低耦合的体现,层内高内聚,层间低耦合,层是层内具体工作的高度抽象。低耦合则是依赖倒转原则体现出来,高层依赖于下层的抽象而不是具体。
1.2四层架构
在三层架构的基础上多了业务规则层,通常的三层是把业务逻辑和业务规则合并为一个层,统称为业务层.业务规则层的提出,既可以及时处理用户输入的不合法信息, 又可以及时处理数据库错误, 增大了业务逻辑层的结构清晰度, 让业务逻辑人员专心致志做逻辑。
从上至下为:
l 表示层
l 业务规则层
l 业务逻辑层或称为领域层
l 数据访问层
层次 |
作用 |
设计原则 |
业务规则层(ECL) |
对于UI层传下来的参数来说,检查合法性。 |
用户至上,兼顾简洁;不包含任何业务相关的逻辑处理。 |
1.3引入service层
引入service层的架构和普通的分层架构的不同是: service层内部有数据, 可以单独运行。
从上至下为
l 表现层
l 服务层(service)
l 数据访问层
l 业务逻辑层
层次 |
作用 |
表现层 |
显示与用户的交互。 |
服务层 |
service层提供表现层的业务逻辑入口,通过定义接口服务的形式,通过接口调用来完成。 |
业务逻辑层 |
1接收服务层传来的DTO, 然后根据业务规则, 对传入的DTO进行加工, 返回加工后的信息 2 需要为每个对象提供业务行为, 并且这些对象之间是独立的 3 业务对象之间的交互流程通过服务层来组织 |
数据访问层 |
本地数据远程数据的访问接口。 |
2.MVC
MVC指Model-View-Controller。
层次 |