CRM一张表单开发的思路

在开发CRM项目的这几个星期里，我遇到了不少困难，最大的困难是对开发一张表单的完整流程缺乏清晰的思路。回想起开发第一张表单时，我完全处于照抄的状态。当时，我负责的是正式客户申请单，而泓宇开发的潜在客户申请单和我的任务非常相似，所以我基本上是照着他的表单一步步模仿，迷迷糊糊地就完成了第一张表单。

然而，问题出现在第二张表单——客户档案表单的开发上。因为没有可以直接参考的模板，我花了整整两个星期，依然没有搞定这张表单。那段时间真的很痛苦，几乎每天都感觉漫无目的，不知道自己在做什么。为了完成任务，我随便找其他表单东抄一点、西抄一点，但最终一团糟，什么成果也没做出来。

后来有一天我实在是受不了了，我记得那天是星期六，我和我同学聊了一通电话，聊了之后又想了一天东西。那天，我明白了，我一直做不出表单的关键在于我连最基本的需求都没有搞清楚。如果你开发一张表单，却连这张表单的需求是什么、最终需要实现什么功能都不清楚，那肯定是无从下手的。因此，我认识到第一步一定是明确需求，搞清楚这张表单的目标是什么、想要实现哪些功能。这一步至关重要。

当需求明确后，就可以进入第二步——梳理表单的开发思路，也就是规划好完成这张表单需要哪些步骤。这一步完成后，其实心里就已经有了很大的底，因为接下来的工作就是按照这些步骤，用代码将它们逐一实现。

前面两步是很重要的，但是我在上篇文章已经讲过了这两步的重要性了。所以今天，我们重点来聊聊如何在代码实现的过程中关注细节。

我们先从后端的开发流程开始讲解。

1. 判断表单是否有表体

如果这张表单没有表体，那么直接使用普通的 controller、service、repository、mapper 和 mapper 的装饰器就可以完成开发，这种情况下只需要一条主线即可。如果表单有表体，但表体不需要单独进行增删改查操作，那么也不用额外开一条线，依然可以复用主表的那条线。

明确了需要开几条线后，下一步就是开始编写代码。

2. 编写代码：重点在 DTO 和 Entity

后端开发中，真正需要你手动编写的部分主要是 DTO 和 Entity，其他部分基本上是可以直接复用或照抄的。由于每张表单的字段各不相同，DTO 和 Entity 的定义也会随之变化。这里，字段设计是最关键的部分，因为表单的字段不仅仅是简单的 String 或 int 类型，还可能包含复杂的类型，比如参照字段和下拉框字段。不同类型的字段需要不同的处理方式。

3. 字段处理：常见类型

以下是一些常见字段的处理方式：

（1）billCode 字段

billCode 是每张表单的必备字段，必须要有。

（2）state 状态字段

state 状态字段是否需要添加，取决于具体的业务需求。尽管业务给出的字段列表中可能没有这个字段，但你需要根据表单的业务场景判断是否需要补充。例如，某些表单可能需要状态字段来标识流程状态（如自由态、审核中、审核通过等）。

4. 参照字段的处理

以“客户”参照字段为例，说明如何处理参照字段。

表单的三个页面

一张表单通常包含三个页面：列表页、编辑页 和 详情页。

列表页和详情页用于展示数据。
编辑页用于填写数据并将字段数据保存到数据库。

参照字段的逻辑

在编辑页中，当你选择了“客户名称”时，本质上你选择的是 customerId。当点击“保存”时，前端会将 customerId 传递到后端。因此，后端的 DTO 中需要定义一个 customerId 字段来接收这个值。

然而，在数据库中，存储的字段可能是 customer，而不是 customerId。为了实现从 DTO 到 Entity 的转换，我们需要在 mapper 中编写转换逻辑，将 DTO 中的 customerId 转换为 Entity 中的 customer。

实现步骤

DTO 的字段设计

DTO 中需要定义 customerId 和 customerName 两个字段。
customerId 用于接收前端传递的客户 ID。
customerName 用于展示客户名称。

从 DTO 到 Entity 的转换

在 mapper 中，编写转换逻辑，将 customerId 转换为 customer 并存储到数据库中。

从 Entity 到 DTO 的转换

在 Entity 中，通过标注实现数据的关联。例如，customer 字段可以通过 CustomerExtApi 方法查找到客户表中的 customerId 和 customerName，并将这两个字段传递到 DTO 中

通过以上流程，后端可以完成对参照字段的处理。

5. 下拉框字段的处理

下拉框字段的处理逻辑与参照字段类似，但稍有不同。

本质

下拉框在前端展示的是具体的文本数据（如“自由态”“审核中”“审核通过”“审核不通过”），但在数据库中存储的却是对应的数值（如 0、1、2、3）。因此，需要在前后端之间进行数据的转换。

转换方式

转换可以通过以下两种方式实现：

前端转换
前端根据数值（如 0、1、2、3）动态显示对应的文本数据。
后端转换
后端接收数值后，通过代码将其转换为对应的文本数据，再返回给前端。

CRM 系统中的处理

在 CRM 系统中，这种转换通常是通过系统配置完成的。例如，对于审批状态字段：

数据库中存储的值为 0、1、2、3。
系统配置中定义了数值与文本的对应关系：
- 0 对应“自由态”。
- 1 对应“审核中”。
- 2 对应“审核通过”。
- 3 对应“审核不通过”。

通过这种配置，系统可以自动完成数据的转换，开发者无需手动编写转换逻辑。你只需要做的就是在前端的某个文件里面自定义枚举，就完事儿了，就像下面这样。

其实这是很方便的，不用程序员手动编写转换逻辑，但是这个叼系统不知道为什么即使我加了枚举，配置的时候下拉没有显示我的自定义的枚举，所以我还要手动去数据库中配置一下才行。

这个字段要手动加上approvestatus，这样系统就会自动你配置的这个枚举标识了，不然找不到，我也不知道为什么。

其实，表单的字段类型无非就几种：最基本的 String、int、BigDecimal、float，再加上稍微复杂一点的参照字段和下拉框字段。只要把这些类型处理清楚，基本上就没什么问题了。

6. 基本文件的准备

当 DTO 和 Entity 都定义好了之后，下一步就是准备数据库。数据库表结构设计好、创建完成后，就可以继续往下推进。

接下来需要确认是否需要写接口。如果不需要写接口，那后端的工作基本就完成了；如果需要写接口，那就把接口写好。接口写完后，后端的代码基本上就差不多了。

7. 用 Postman 测试

写完后端代码后，必须用 Postman 进行测试。这一步非常重要，因为如果不测试，你无法确认写的接口是否正确。例如：

如果接口逻辑有问题，可能会导致数据无法正确返回。
即使在 CRM 项目中不需要写接口，也可以通过 Postman 测试来验证 DTO 和 Entity 的数据转换是否正确。

总之，Postman 测试是后端开发中不可缺少的一环，确保接口逻辑和数据处理没有问题后，才能继续下一步。

8. 前端的开发

测试完后端接口后，就可以开始处理前端部分了。不过，这个 CRM 系统和其他系统有些不同，前端不需要写代码。前端的页面是固定的模板，类似一个写死的页面雏形，直接拿来用就可以了。

前端的开发流程

找到一个合适的页面模板。
将模板搬过来，根据需求稍作修改即可。

前端的开发几乎没有技术难度，关键在于系统配置。

9. 系统配置

系统配置是整个流程中比较特殊的一部分。一开始可能会觉得配置很复杂，但熟悉之后就会发现，这其实就是流水线式的工作。只要按照步骤逐一完成，就不会有什么难点。

10. 最终测试

当所有步骤都完成后，最后一步就是自己手动操作一下表单，检查增删改查功能是否正常。如果没有问题，这张表单的开发就算彻底完成了。