一个通用程序的相关原理

一个通用程序的相关原理

因素

------------------------------------------------------------

【数据结构】

层次

vd 客户端展示控件数据结构/打印/导出

vcd 客户端内存数据结构

td_view 传输时json/xml结构

cd 计算时内存数据结构

td_cache 传输时json/xml结构

pd 持久化层数据结构

rd 表结构

 

结构

原子数据结构string/number/date/boolean/guid/bytes/binary

简单业务数据结构businessobject

单子业务数据结构qjd(master,List<List<detail>>)

主

基本属性

引用对象

基本属性集合

引用对象集合

子

基本属性

引用对象

基本属性集合

引用对象集合

参数业务数据结构define(info,bytes)

 

映射

基本映射

关系映射

继承映射

 

基本

string/number/date/boolean/guid/bytes/binary

关系

多对一

一对多

多对多

继承

parent

parents?

【数据/状态】条目

层次

vdvcd + 格式化/反格式化

vcdpd + 计算逻辑/处理逻辑

tdcd + 序列化/反序列化

cdpd + 计算逻辑/处理逻辑

tdcd + 序列化/反序列化

pdrd + 持久化逻辑

rd持久化数据

 

【状态变化范围枚举】

状态变化要求和逻辑类别，场景时机类别紧密配合，要求严谨。

【状态之间具有【依赖】关系，认为是一个状态组合，具有【原子性】和【完整性约束】，那么状态的变化就要考虑这个组合变化的严谨性】

【状态的冗余？】

【状态存在具有条件性？】

状态B是某个状态值的条件是状态A在某个状态值下。

【一个业务功能内部状态间具有【原子性】和【完整性约束】】

功能内的状态，逻辑，场景的严谨性

监听，连带修改？

【多个业务功能的状态间具有【原子性】和【完整性约束】】

多个功能间的状态，逻辑，场景的严谨性

重置单据？

 

【逻辑部件类型】类

概念一个概念封装成一个逻辑部件

职责这个概念拥有的状态和逻辑代码，应该写在这个逻辑部件中

【逻辑部件】对象

生命周期参考后边的场景，定义逻辑部件应用的范围，什么时候产生，什么时候销毁，创建个数。

实例个数考虑不同场景下，操作的是否是同一个对象。别看到有代码在修改状态，就认为影响的是本对象。

状态是否有状态，有的话考虑逻辑部件的【并发】情况。

逻辑逻辑是否在操作自己的和别的地方的状态，有的话考虑逻辑部件的【并发】情况。

【逻辑】方法

方法

代码不要把逻辑和时机混为一谈，逻辑本身可以在多个时机调用，逻辑代码应该写在逻辑部件中。

 

【逻辑类别范围枚举】

状态变化要求和逻辑类别，场景时机类别紧密配合，要求严谨。

 

【视图】

数据

vd

vcd

控件

值

可选值列表

属性

折叠状态

选中状态

......

颜色

大小

......

事件

布局

 

【场景/时机/事件/系统级行为/功能级行为】

开发 影响所有运行生命周期

开发代码

配置参数

运行

启动

模块加载全局生命周期

运行

用户登录用户会话生命周期

一次业务功能的执行（打开一个功能）一次完整业务功能生命周期

功能执行中用户操作的场景一次业务功能内完整操作的生命周期

一次请求一次http请求生命周期

 

从需求中找到场景，从场景中分析状态和逻辑

 

【场景时机类别范围枚举】

状态变化要求和逻辑类别，场景时机类别紧密配合，要求严谨。

 

系统级行为

启动

登录

一次业务功能的执行，打开一个功能

功能级行为

操作

行为事件

程序事件

 

【时序】

多个执行时机的先后顺序，影响状态是否按需求变化。

 

界面上一个操作没有响应回来，就开始下一个操作：

遮罩

一个操作多个事件：

文本失去焦点时，点击了另一个单选钮控件。

一个事件导致后端代码执行时,因为多层监听器导致时序复杂混乱：

界面修改A --> 后端修改A --> 公式修改B --> 公式修改C --> 公式修改A?

什么时候从控件到模型？

什么时候从模型到控件？

什么时候记录一些其他状态？

 

应用

------------------------------------------------------------

参数设计

单据录入

列表查询

......