PHP 转 Java ，上千张表需要 CRUD

mybaitis-plus 看看文档就能搞

mybaitis-plus 一键生成

闲得蛋疼才重构。

这不是吃饱了撑的么，PHP 继续迭代跑呗。

@BaiShui 没有通用的吧，还得逐个表搞代码。也缺少 controller 那一套东西

@zhengshangjin 太老了，漏洞补不了了，刚搞 XC ，一起换了...

IDEA 很多插件能一键生成

@VensonEEE mybatis-plus 不是有插件根据表字段直接生成 controller 、service 、mapper 嘛

@zvvvvv 还有实体对象

有没有不用生成的，生成几千个文件也很糟心，那种连上数据库就能提供 api 的...

如果都是生成的话 不得有上万个类啊。。这 Java 项目编译一下得多慢？

这些表有没有什么共同点？没有的话怎么搞出几千个的？

自己封装一下, 直接 JdbcTempleate 执行 sql

plate

团队多少人，这种重构应该要分多个服务

要不看看 Jeecg 的代码生成，然后看能不能借鉴。批量导入表，批量生成代码

mybatis + pageHelper 就行了，可以试试 intellij 插件 MybatisCodeHelperPro 快速生成代码

你可能需要低代码框架：不生成代码，直接启动数据库的 crud 的 GraphQL 接口，后端几乎不用写代码，让前端直接调用 GraphQL 接口。

https://github.com/graphile/crystal
https://github.com/SeaQL/seaography
https://github.com/nocodb/nocodb
https://github.com/nhost/nhost

不如直接针对 php 项目写个转译器转换到 java jpa 。

@VensonEEE #10

Spring Data REST
Spring Data JPA

如果功能一样，看能不能写个代码生成器

mybaitis-plus

你可能对 java 有什么误解，写代码要灵活。不用生成类，循环读取表，根据表字段动态生成 sql ，我刚毕业那会就做过，大概是报表系统类似的需求

@potatowish 控制器中，一个接口共用，参数传表名、字段名

easycode 插件可以生成 controller ，service 层代码，还可以自己用 velocity 写模板

velocity 模板生成，其它类似模板也行

mybatisplus + idea 插件 mybatisx 但是只能生成 crud 而且是 jsp 还是接口，接口这块应该是要自己写的

重构不彻底，不如不重构，接着在原来的代码屎山上开发 :)

@XCFOX #17 你这是让 op 不用重构后端，改成重构前端是吧；
再则，GraphQL 对于客户端真是噩梦 （又或者是因为我只是一个很菜的客户端）

大家觉得这个怎么样？
大量重复代码，我感觉很难接受... 编译速度，启动速度，内存，都是难以接受的。
#22 是个办法 ，我想找个成熟点的，少修 bug 早下班...

@VensonEEE #29
国内开源项目不建议使用

1. PHP 到 Java ，换语言本来就工作量大，不仅仅是 CRUD 操作工作量大。可以考虑重新设计，用 Java 重写。

2. 表多不用 ORM (object-relational mapping) 就行，上面已经有人说了用 JdbcTemplate 。

你是想要一个读取数据库的工具？
php 的大部分逻辑都没问题的话，就继续保留，你就直接调用他的接口就行，php 不对外，把 php 当做一个中间层，

如果只有你一个人 建议别动算了，怎么方便怎么来 能跑就行，千万别想着大动干戈，不然这年都过不好了

让 PHP 老项目继续跑着。新需求开新项目，随便什么你喜欢的技术栈，你这个偏业务的项目核心就是读数据库呗。然后渐进式的替换掉老接口。部分 common lib 直接 gpt 转写或者放 db 的 function 里呗

@XCFOX #17
@VensonEEE #28

我想问一下，GraphQL 与 APIJSON 的使用场景。

APIJOSN 我看了下它的文档，知道 APIJSON 本质就是一个可以在 json 里嵌入 sql 语句的 sql 方言。

GraphQL 的 server 我看了下，
和云厂商的 serverless lambda 差不多，serverless 要用户写每一个 api 的实现，
GraphQL 同样需要用户写每个 query 与 mutation 的实现,
serverless 通过 step-functions 来组合不同 api 到一次请求，GraphQL 通过其语法来组合不同查询到一次请求。

写通用的工具生成下就行了 基础的都有了 就看你自己怎么定义模板的问题

@zjsxwc 大量的业务表，低代码，多租户；以至于传统的 controller services mapper model 那一套不适用了。
另一个是接口大多，大部分都是重复的工作量。怎样准确、统一的完成业务，不就得这么玩么。

erupt

从写单元测试开始。上千的表。接口也差不多上千了。你怎么保证重构完了一摸一样的结果和逻辑？

按回车按快了。。
另一方面肯定不是一蹴而就，前面网关做分离工作，迁移一批网管流转新流量过来一批。反正这么大的规模，就算是看起来是差不多的业务逻辑，但凡错一个，估计得祭天。

为什么要重构呢，要不试试 Go ，或者换 PHP 的 swoole 类型的框架。

PDManer 看下这个，可以根据表来生成 controller service mapper entity 代码

逻辑基本都一样,那就还好了,无所谓多少张表,自己写个代码生成机解析库表自动生成

这种谁弄谁死；
唯一的出路是逐步替换慢慢迁移

我们开发个 APISQL 的中间件，不用写 JAVA 代码，直接用 SQL 生成 API ，自带分页。

如果只是每张表的基本 CRUD ，上千张表应该没什么压力。

只是再改改软件，让批量对整库每张表生成 API 的问题。

请到 www.apisql.cn 试着联系我们，看不能帮上忙。

少了字:(，回复不能修改，再发一下

我们开发个 APISQL 的中间件，不用写 JAVA 代码，直接用 SQL 生成 API ，自带分页。

如果只是每张表的基本 CRUD ，上千张表应该没什么压力。

只是再改改软件，让批量对整库每张表生成 API 的问题。

请到 www.apisql.cn 试着联系我们，看能不能帮上忙。

谢谢各位。

@llf007 这个是要内网部署的。所以谢谢你了。
@wu00 @sampeng 大部分都是 crud ，有一些特别的操作肯定是要自己写代码、上测试套装的。
时间也不急，因为很久没更新了。单纯的不想写 crud 以及搞几千个基础的类。启动太慢了。

是的，支持企业内网私有化部署。

又不是不能用.jpg

从业多年，没见过几千张表的项目.....

2023 年了，还有人不知道 meta(facebook) 开源的 graphql ，都快 20k star 了，强烈推荐
t/589138

graphql 不用写代码，基本啥都能搞定

上千表说明业务够复杂，这个也敢动？