# ewa

**Repository Path**: ghj2qs_admin/ewa

## Basic Information

- **Project Name**: ewa
- **Description**: Standard of Enterprise Web Application.
企业级Web应用规范。
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2021-11-11
- **Last Updated**: 2022-06-02

## Categories & Tags

**Categories**: Uncategorized

**Tags**: 企业级Web应用

## README

# 企业级Web应用标准的构建思路

参考王东岳的说法，知识的产生有三种方式：

1. 演绎，大前提、小前提、推论即三段论。
2. 纯粹思维，比如《几何原本》，由23条极简单明确的定义和最简单明了的几个公理和公设出发，构建一套复杂的知识体系。
3. 归纳，比如我看见非洲的天鹅是白的，欧洲的天鹅是白的，亚洲的天鹅是白的，因此得出天鹅都是白的这一知识。

归纳的缺陷在于只能证伪不能证明，就像我们做软件研发，一家用户这样，两家用户也这样，于是我们就假定了所有用户都这样。
但到了第三家人家不这样了，于是我们不得不推翻之前的假设，造成研发工作量增加。

演绎的问题在于如果大前提错了，那么推论就会错，如果由归纳得出的知识作为演绎的大前提，
由于归纳只能在一个有限范围内为真，因此由归纳得出的知识作为大前提的演绎是靠不住的。

纯粹思维获得的知识，在于如何找到与现实世界的契合，比如有一些数学推导的一些方程， 正确性是能够保证的，但是不知道在哪里应用。

企业级Web应用的标准的制定，乃至任何标准的制定，只要是按归纳得出的结论构建的，必然不够稳固，应尽少地排除归纳的成分，
尽量保证其基础是纯粹的思。

## 重新认识EWA
#### 信息的"分"与"合"
企业级Web应用的背景是生产分工明确，生产过程需要进行数据记录，其目的一是方便生产工作的调度， 二是使数据汇总分析得以实现。
如果没有分工，什么事都是一个人做，或者所有人做相同 的事，它不需要调度，它的统计顶多用一个excel表就能搞定。
企业级Web应用即是**分工**背景下的数据记录。并且今后的生产也必定是分工的。
分工决定了不同分工的主体向系统输入的数据必定是不同的，而工作的调度和数据汇总分析的要求，又让数据必须能够整合， 
因此企业级Web应用中必然有*权限（访问控制）*和*集中化服务*（即Web应用、B-S系统）这两个概念， 
这两个概念分别实现了信息的*整体中隔离*和*分离间整合*的作用。

#### 信息的”合“与”分工“与关系型数据库
分工导致各作业环节相对独立，导致各环节的数据记录通常能够对应一个相对独立的数据库表；因为各环节的多次数据记录的数据结构（该环节拥有的属性）会雷同，与
关系型数据库的”一行数据“相对应。关系型数据库能够实现综合统计查询，是与信息需要整合的需求相对应。

#### 权限控制与HandlerMethod
根据RBAC(INCITS 359)规范，permission=operation+object，即"权限"等于"操作对象"，摘录一下object的定义：

objects:As used in this standard, an object can be any system resource subject to access
control, such as a file, printer, terminal, database record, etc.

照次定义，我想当然地想把领域逻辑模块当作一个object，因为它更像是一个东西。当用户想调用任何领域逻辑模块的接口时，
对其进行访问控制，而不是传统的把权限控制加在HandlerMethod上（此为Spring的一个类，此处泛指提供http服务的一个点）。
但是按传统，我们是把权限按功能点（与分工对应）分组，权限与一个或多个HandlerMethod对应。
如果按给领域逻辑模块进行访问控制的方式，我们分配权限时就非常困难了。
因此权限控制需要加在HandlerMethod上，是合乎深层的逻辑规定的。EWA的权限控制是面向现实世界的分工的。
那么operation+object中的object是什么呢？object就是所有HandlerMethod的集合，就是**业务服务**。

EWA中还常有Open Http Api，通常是token方式鉴权，与HttpSession鉴权不一样，我认为两者应为同一个鉴权体系。
因为不论是token方式还是HttpSession方式，都是想要控制对**业务服务**的访问。

业务服务的分类常常按作业环节分，如amili框架下的bundleId，比如分离前处理环节，object即为"分离前处理业务",
operation即与actionId对应，比如“处理”，“审核”。Object到底要按环节分，还是按更大的环节分，这应该是灵活的。
Amili框架中的权限实际上是权限组，而不是一个权限，但这也应是灵活的。

#### 岗位与角色
岗位如果看作组织机构的一种，那么无所谓，和部门、公司是一个性质，不过是组织机构树的一种节点。
如果岗位代表用户的职责，那么与角色（代表用户的职责）这一概念的作用有重叠。现实业务中有“一人多岗”的情况，
EWA中可以通过一人赋予多个角色来描述。因此角色应作为代表用户职责的唯一概念。
至于岗位，只能当作组织机构树节点的类别（如公司、部门）的一种，且也应是灵活的。

## EWA标准的设计理念
#### 面向描述
所有的程序，都可以看作是一份在某语言体系下对某个思维逻辑内容的描述，能够识别并运行该程序的是某种程序运行环境。
EWA标准旨在构建一套描述方式，期望使用该描述方式能够带来如下优势：
1. 精确；描述信息充足且不多余
2. 符合EWA深层逻辑，从而整洁、简单，易学易用；程序尤其是人类思维产物，因此可以是天马行空的，
所以必须要对其加以限制，限制的方向就是贴合被描述事物的深层逻辑，这样有利于用户达成共识。

#### “如无必要，勿增实体”
奥卡姆剃刀原理。如无必要，勿增概念。人们常常把仅仅是表面上不同的东西当作不同的东西。

## 将类当作配置文件
Applet部分，为了有良好的描述性，使用了类作为Applet的元信息源。
定义必为全局唯一的单例，既然是单例则不必非要用一个单例模式，该类的Class对象即为单例。
定义不必在运行时改变属性，因此没必要实例化。
同一领域不可能有相同的概念，不同概念必定有不同的名称，
因此使用Class的SimpleName作为定义的id(全局唯一)为最简做法。
在开发过程中使用IDE的类名重构即可统一修改，减少研发负担。
基于上述原因，把类当作某定义的元信息源为最佳做法。

## EWA标准的范围
#### applet（对应某分工作业的功能或统计功能或其他等功能）
#### rdb（面向关系型数据库的通用描述）
#### 杂项（杂项应该属于一个更抽象一级的标准，涉及到整个Web应用的构建理念）