搭建合适的Web框架

ntroller,Service,Model,Mapper等一系列的类，也就是说，只要建完表，就可以直接生成一套CRUD，直接就可以启动并测试。这在项目初期看起来很美，但是在需求变动时，还是有很多的局限性。

首先，生成的代码逻辑是固化的。如果稍微有些调整，就需要调整生成代码的组件，然后重新打包，上传到jar仓库，项目修改组件版本，再进行代码生成，整个流程过于繁琐。

其次，为了方便代码的生成，其实是做了不少妥协的：

• 为了方便在修改表字段以后，能够重新生成，很多类都抽象了一个基类用于操作Model字段。这些基类不能够手动修改，因为每次生成都会覆盖。这实际导致了类的数量的增多。
• 生成的CRUD固化了，不能手动调整。如果生成的CRUD不满足需求，不能直接在代码上修改。只能拷贝一份进行修改，因为再次生成时会覆盖。这导致了代码的冗余。
• Param和Result委托了Model，这在Model发生改变时，能在编译期就能知道对应字段的调整。但是也引入了不少问题，我们在「参数传递问题」一节单独讨论。

参数传递问题

当初为了便于代码的生成，决定Param和Result都继承Model，这导致了如下的一些问题：

• 使得Param和Result都依赖了Model。但是Param和Result是视图层模型，而Model是持久层模型，两者的进化度并不是一致的。但是现在的继承关系导致了在默认情况下视图层模型的进化需要和持久层同步，当然你也可以手动调整Param和Result，但是这又导致了代码生成的优势没有了。
• Param和Result通过委托的方式来设置字段，也就是说，它们实际是没有字段的，通过getter和setter将值设置到了Model中。这就没法使用lombok来简化getter和setter，使得Param和Result代码行数较多
• 同时，对于swagger来说，有些注解需要基于字段，导致某些功能无法实现(例如：ModelAttribute)，只能基于额外手段来处理(例如：需要通过ApiImplicitParams来实现字段文档)。
• CRUD都是基于同一个Param和Result，导致前端的接口会显示很多无用的字段，加大前端理解接口的难度

Service层问题

Service层有如下问题：

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!