如何消除编写重复的 CRUD 的工作？

lhx2008

2018-10-02 15:29:12 +08:00

用生成器->性能损失->用 JPA

weizhen199

2018-10-02 16:01:04 +08:00

mybatis plus 了解下

wshcdr

2018-10-02 16:01:24 +08:00

脚手架啊

likuku

2018-10-02 16:27:38 +08:00

试试自己写生成代码的工具代码（用代码来生产代码，至少可以最大程度不影响他人已有的习惯)

wd

2018-10-02 16:29:27 +08:00

用 orm ？

x66

2018-10-02 16:29:48 +08:00

@lhx2008 JPA 比生成器生成出来的代码效率高？？

version

2018-10-02 16:31:45 +08:00

模块化. rpc . 分业务用 redis 来储存还是 mongodb 还是 mysql 这样进步也快呢.
如果单纯 crud.高并发.多事物.改需求是一个大难题.只能重构

GTim

2018-10-02 16:35:23 +08:00

@lhx2008
@wshcdr

赞同

misaka19000

2018-10-02 16:54:45 +08:00

用 jpa

luozic

2018-10-02 16:55:45 +08:00

看场景，现代硬件就是用了 orm 也一般不是性能瓶颈。

TommyLemon

2018-10-02 16:57:56 +08:00

CRUD 确实无聊，用自动化 API 解决吧。

APIJSON 自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
github.com/TommyLemon/APIJSON

TommyLemon

2018-10-02 16:59:06 +08:00

@TommyLemon 提供了 SpringBoot 的 Demo 哦。

TommyLemon

2018-10-02 17:32:19 +08:00

@TommyLemon
APIJSON 目前后端有 Java, C#, Node.ts 实现，
前端有 Android-Java, iOS-Swift, Web-JavaScript, Web-Vue.js 实现。

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
https://github.com/TommyLemon/APIJSON

xcjx

2018-10-02 17:49:51 +08:00

对于多个表增删改查的无聊，没有什么根本的解决方法。如果有，那也只有这一种：好好干，升职了后，把这些烂活儿交给别人干。

JmmBite

2018-10-02 18:11:34 +08:00

意念编程。

AltairT

2018-10-02 18:47:43 +08:00

用 mybatis 生成器只能生成简单的语句，还是习惯自己写 sql,jpa 虽然也能写 sql，但是对于复杂的语句还是不习惯

zw1one

2018-10-02 19:11:08 +08:00

用工具根据表结构生成基本的 crud 啊，然后再按需求改改

bobuick

2018-10-02 19:56:52 +08:00

自己往死里设计，封装你那部分业务就不会那么无聊了。而且把它当作你实验，想想貌似也还不错。
以下是今天看到的一个例子：
1.本来的 CRUD，例如一个 transfer service，把 Account1 余额转给 Account2
本来的写法，过程式：减 A1，if 检查 balance 是不是为负了，负了抛异常结束，然后给 A2 加余额，结束。

改成：
A1 呢不再是个贫血模式，看作 DDD 的设计模式来玩，加个 debt 方法，然后 Account 类呢，加个 OverDraftPolice 接口，用策略模式，当前业务可能不允许透支，但万一可能扩展呢？哈哈，实现个不允许透支但 OverDraftPolice 的 Impl

然后把 Account 类里组合包含这个 Police 接口，然后呢 transfer 就写成这样了：
account1.debt(amount)
account2.debt(amount)

这里面把 Police 规则封装进去。

类似这种玩法，要是平常写过程式较多呢，就换个风格玩。你说有啥实际好处没？多数情况下答案是：有个大几把好处，业务要是能随码农感觉变动就不叫业务了。

不过好歹自己玩过了，不会那么无聊啊。

sgz

2018-10-02 22:47:03 +08:00

mybatis plus 了解一下

est

2018-10-02 23:25:10 +08:00

还是挺怀念 vb6 时代的。做 CRUD 报表直接拖控件。选择数据源绑定 sql 即可。