从数据网络编程到业务网络编程：编程语义、业务架构量化分析

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的，没道理进入网络时代逻辑就不是这个业务逻辑了，只是针对在网络传输中对数据的传输与同步衍生出分层设计。
网络业务因为种种问题拆分出多层，如果我们能够解决这些问题，那么重新将这些层重新归一也是合情合理的。
我们先谈一下好处：

1. 我们会有一种回归单机版编程的语义感
2. 省却了繁琐的数据处理，毕竟数据处理其实大部分都是重复性操作
3. 能够直接面向业务，入手即业务总好过入手先分层
4. 能够运用面向对象设计模式

重点是第四个，可以呈现出多态特性，甚至包括工厂模式、访问者模式等都可以直接运用到网络编程中
（想象一下，服务方通过工厂模式返回一个特定需求的业务对象，比如Mobile_User PC_User）

结语

第一章比较短，基本介绍一下我们做些什么，后续会涉及造成分层问题的解决方案，最终效果将呈现出与上述一致的效果（甚至更棒~）。