|
副问题[/!--empirenews.page--]
之前在Web开拓框架推导一文中我们一步步的搭建了一个开拓框架。
在其时的环境下，还算满意需求。可是跟着项目标逐渐完美，需求改观的频度逐渐变得比新增需求的频度高，原本框架的破绽越来越明明，以是必要对框架举办进级改造。
我们先来看原本框架的题目，然后基于这些题目，来对框架举办改造。
原框架的题目
- 代码天生题目
- 参数转达题目
- Service层题目
- 测试依靠题目
- Mapper.xml的题目
代码天生题目
在原框架中，我们基于各类束缚，编写了一个代码天生组件，通过这个组件，我们可以针对选中的表来天生Controller,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层有如下题目：
- Service层的职责过重，包罗了事宜处理赏罚、参数配置、营业逻辑
- 导致Service中的代码是面条代码，倒霉于营业逻辑的领略
- 同事势务注解是直接加在类上的，Spring的默认事宜机制会导致相同如下代码的逻辑挪用不会抛出祈望的非常
- // PostService
- public String savePost(Post post) {
- postRepository.save(post);
- for(PostDiscuss discuss : post.getDiscuss()) {
- // 这里是抓不到RuntimeException非常的，会是一个TransactionRollBack的非常
- discussService.save(discuss);
- }
- }
- // discussService
- public String savePost(PostDiscuss discuss) {
- throw new RuntimeException("生涯失败");
- }
测试依靠题目
焦点的营业逻辑在Service中，测试照旧必要依靠于Spring，当项目越来越大时，启动项目标时刻越来越长，也许要1分钟乃至更长。这就导致单位测试服从越来越低。
Mapper.xml的题目
在口试的时辰，我常常会问下面的一些题目：
- Java内里接口的浸染是什么?
- Service、DAO为什么要编写接口，再去实现这个接口?
- 接口和实此刻沟通的模块下，横竖都要从头打包的。多写个接口不是多写了好几行代码吗?
- 和上面相同的题目，Mybatis内里，声称将sql独立到了Mapper.xml文件中，使得可以不必要编译直接修改sql。但Mapper.xml都是和Class放在一路的，改了照旧必要从头打包，并且Mybatis是不能动态加载Mapper.xml的，那把sql独立到XML里，到底有什么上风?
对付最后一个题目，我的谜底是，对付大部门项目来说，没什么上风!项目易不易于陈设、扩展，不在于你行使的框架，而在于你的计划。
就以Mapper.xml来说，Mybatis将sql与代码疏散了，可是你在项目里照旧将Mapper.xml和代码放在统一个模块下，那这个上风就没有了。既然没有这个上风，我们尚有须要单独写Mapper.xml文件吗?我的选择是，那就不写了，直接行使Mybatis提供的注解。
同时为了办理Service层对DAO层(这里也就是对Mybatis)的强依靠，对框架举办了一些改造，解耦Service和DAO层。详细见下面的改造方案。
框架改造方案
为了办理上面这些题目，对框架举办了如下调解：
- 疏散Param、Result和Model
- 替代代码天生
- 独立营业逻辑
- Model层优化
疏散Param、Result和Model
（编辑：河北网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
