tip:一杯咖啡足够了
面向网络业务对象编程专栏
第一章 网络分层归一化
代码量
架构
面向业务
面向数据
同效代码
面向业务
理论上最简明的代码逻辑
//创建业务对象
User user = new User();
if(user.login()){
System.out.println(patient.getUsername() + "登录成功");
}
else System.out.println(patient.getUsername() + "登录失败");
面向数据
采用的Service+DTO(面向数据)的代码逻辑
//创建Entity
User user = new User();
user.setUsername("839336369");
user.setPassword("123456");
//配置Request
LoginRequest loginRequest = new LoginRequest();
loginRequest.setUsername(patient.getUsername());
loginRequest.setPassword(patient.getPassword());
//创建Service
UserService service = new UserService();
//获取Response
LoginResponse loginResponse = service.login(loginRequest);
if(loginResponse.isSuccess()){
user.setMoney(loginResponse.getMoney());
System.out.println(user.getUsername() + "登录成功");
}
else System.out.println(user.getUsername() + "登录失败");
归一化
网络业务拆分
可以发现,面向数据代码量明显多于面向业务。
其实也不难看出原因,我们拿User
业务对象来讲。
User
对象拥有属性:username
password
money
方法:login
,通过调用login
方法,验证username
、password
得到money
。
在网络化时,User
根据login
方法,拆解为四个组件:Entity
Service
Request
Response
网络业务归一化
上述对单体BO对象的拆分比较常见,毕竟单机时代就是这么写BO的,没道理进入网络时代逻辑就不是这个业务逻辑了,只是针对在网络传输中对数据的传输与同步衍生出分层设计。
网络业务因为种种问题拆分出多层,如果我们能够解决这些问题,那么重新将这些层重新归一也是合情合理的。
我们先谈一下好处:
- 我们会有一种回归单机版编程的语义感
- 省却了繁琐的数据处理,毕竟数据处理其实大部分都是重复性操作
- 能够直接面向业务,入手即业务总好过入手先分层
- 能够运用面向对象设计模式
重点是第四个,可以呈现出多态特性,甚至包括工厂模式、访问者模式等都可以直接运用到网络编程中
(想象一下,服务方通过工厂模式返回一个特定需求的业务对象,比如Mobile_User
PC_User
)
结语
第一章比较短,基本介绍一下我们做些什么,后续会涉及造成分层问题的解决方案,最终效果将呈现出与上述一致的效果(甚至更棒~)。