更新 llms-full.txt
This commit is contained in:
@@ -1030,13 +1030,13 @@ DateTime endTime； //会议结束时间
|
||||
```
|
||||
- **代码产物和修改建议**
|
||||
- **Service:**
|
||||
* **生成产物:** 在对应的聚合服务BoService里生成一个函数
|
||||
* **生成产物:** 在对应的聚合服务BOService里生成一个函数
|
||||
* **函数命名规则:** 和写方案同名
|
||||
* **职责:** 按需对入参进行转换，调用BaseBOService里的函数完成对聚合对象的操作, 实现对数据库的写操作；
|
||||
* **BoService的类路径:** ```**.service```
|
||||
* **BOService的类路径:** ```**.service```
|
||||
* **唯一标识符位置:** 其对应的标识符在函数的注解@AutoGenerated中指定, uuid规则: ${WritePlan在TOCO中的uuid}
|
||||
- **BaseBoService**
|
||||
- **生成产物:** 在对应的聚合的BaseBoService里生成一系列函数，根据入参完成对聚合对象的变更
|
||||
- **BaseBOService**
|
||||
- **生成产物:** 在对应的聚合的BaseBOService里生成一系列函数，根据入参完成对聚合对象的变更
|
||||
- **职责** 增对每个实体的生成增删改的函数，并且根据参数的结构以及聚合的结构，构建嵌套的调用逻辑，完成对一个聚合对象的变更，记录并且返回对应的变更情况
|
||||
- **类路径:** ```**.service.base```
|
||||
- **禁止** 修改该类
|
||||
@@ -1050,7 +1050,7 @@ DateTime endTime； //会议结束时间
|
||||
- **例子：**
|
||||
- 创建用户以及用户设置的写方案create_user_and_setting，生成CreateUserAndSettingBto, 在用户的聚合(UserBO)对应的UserBOService中生成函数createUserAndSetting，该函数调用BaseUserBOService中生成的createUserAndSetting, 其中在BaseUserBOService中还生成了createUser和createSetting的函数, 一起完成了用户的创建和设置创建的逻辑。
|
||||
- **修改建议：**
|
||||
- 不能修改BaseBoService中的函数，不建议修改BTO文件。建议在BOService中进行手动代码扩展，处理可能被复用的修改前后的逻辑，如修改数据库的前后值对比、或常被复用的校验逻辑（业务不变性校验逻辑除外）、需要经常在一个事务内执行的其他写操作等。
|
||||
- 不能修改BaseBOService中的函数，不建议修改BTO文件。建议在BOService中进行手动代码扩展，处理可能被复用的修改前后的逻辑，如修改数据库的前后值对比、或常被复用的校验逻辑（业务不变性校验逻辑除外）、需要经常在一个事务内执行的其他写操作等。
|
||||
|
||||
#### **2.12 业务变更传输对象(BTO)**
|
||||
- **定义与用途:** 在TOCO中，BTO为写方案自动生成的参数结构，每个写方案会生成一个BTO。BTO为写方案选定的操作实体根据关系形成的树形集合，最外层为聚合根。写方案调用方按照BTO的结构向写方案生成的RPC方法传入需要操作的实体字段值，完成对数据库的写操作
|
||||
@@ -1310,11 +1310,11 @@ requestParams为请求参数列表，response为返回结构，requestParams中
|
||||
│ ├── dos/ # 数据库单表结构的映射
|
||||
│ ├── qto/ # 读方案的数据库查询实现
|
||||
│ └── mapper/ # MyBatis的Mapper定义
|
||||
└── service/ # BoService（包含某个聚合下所有写方案生成的方法）、 DtoService（包含DTO生成的预定义方法）
|
||||
└── service/ # BOService（包含某个聚合下所有写方案生成的方法）、 DtoService（包含DTO生成的预定义方法）
|
||||
├── bto/ # 写方案入参的定义
|
||||
├── converter/ # 对返回的BaseDto按需进行二次扩展
|
||||
├── query/ # 查询方案的service层入口，调用persist层的查询实现
|
||||
└── base/ # 每个BoService对应的基类
|
||||
└── base/ # 每个BOService对应的基类
|
||||
在一个子模块的内，它的依赖层级为entrance -> service -> manager -> persist, 同时各个层都依赖 common
|
||||
```
|
||||
|
||||
@@ -1350,7 +1350,7 @@ requestParams为请求参数列表，response为返回结构，requestParams中
|
||||
- 写代码时请注意，BOService一般是用于写，QueryService一般是用于读
|
||||
- 输出代码前请仔细检查是否有错误的import，如果有则将其修正
|
||||
- 对于无法识别或直接生成的参数和逻辑，请增加一个相关的//TODO注释，把从需求中解析到的可能的处理逻辑以java伪代码的形式写在注释中
|
||||
- BoService 函数中的 boResult.getRootBo() 一定存在，不要添加判断null的情况的代码; 不要添加调用rootBo.persist()的代码（该方法的触发由生成的代码负责），在BoService的函数中不要修改和注销系统生成的代码（通过/** This block is generated by vs **/注释标注部分)
|
||||
- BOService 函数中的 boResult.getRootBo() 一定存在，不要添加判断null的情况的代码; 不要添加调用rootBo.persist()的代码（该方法的触发由生成的代码负责），在BOService的函数中不要修改和注销系统生成的代码（通过/** This block is generated by vs **/注释标注部分)
|
||||
- 在函数中的不同片段逻辑，使用 {} 标注分块，附上注释，提升代码的可读性
|
||||
- 以准确性作为第一优先级（不产生编译错误），不要直接生成不存在的函数、字段的调用； 如果逻辑上必须依赖，可以使用注释来表达
|
||||
- 写代码时，如果发现有用户指定的上下文，则优先判断是否有可用的代码；如果用户有编写代码的特殊要求，则优先满足用户需求；如果前面已经有过规划信息，则尽量按照之前的规划来做，比如业务不变性的分析等
|
||||
|
||||
Reference in New Issue
Block a user