Spring Data JPA 和 MyBatis 谁更强？( 二 ) _Spring

于是我们可以看到99%的代码结构就是：

Controller - 几乎没代码
Service - 重灾区
Utils - 重灾区
Entity - 跟VO有啥区别？
Repository 或 MApper 或 Dao - 几乎没代码
Mapper.xml - 证明我是SQL小王子的时候到了
Test - What? 这干嘛的？

Service太重了，随便翻开一个Service，里面的代码一大堆。
不信随手翻一下现有的项目，超过一千行的Service是不是到处都是？
我形容这种开发为猪突式开发。
那么这个时候，MyBatis牛逼的地方就显现出来了。
幸好还有个Spring框架如果没有Spring框架，什么OOP，扯犊子呢？抓紧往上怼怼怼怼代码，怼完拉倒。
框架是为了简化开发任务，让你有更多的时间去做程序设计和逻辑架构。所以，哪个会更流行取决于大环境，而不是开发人员。我本人是更喜欢先设计，后开发的。
但是我同样是一个有同情心的人，我不忍心破坏别人想当一个架构师的梦想，虽然他可能一行代码都没写过，我依然支持他，当然前提是该背的锅你得背，该我的钱一个子儿都不能少。
说些题外话我个人有三种开发方式，第一种是前端驱动，第二种是后端驱动（好像说的是废话……），第三种是数据驱动。
前端驱动顾名思义，就是做一个项目，前端先上，前端根据设计稿和产品文档实现了UI之后，后端再根据前端UI去设计后台架构。这么做的好处在于无论是客户还是开发，都能面向一个具体的页面进行需求讨论和架构设计，最终实现结果不会跑偏。
前端的开发速度是比后端快的，因此在发生需求变动的时候，响应速度也非常快，实在有一些比较难处理的UI，例如需要Canvas绘图的地方，通过口头（或文档）补充即可。但是这种方式只适合一些面向客户的小项目，而不是面向产品的项目，就是说客户要什么就给他什么，他要一匹马，你就别给他设计一辆车，到时候吃力不讨好。

这种类型的项目，MyBatis最合适。

如果一个项目非常大，例如从头开始设计一个B2B的交易平台（包括后台ERP）产品，就不能采用这种方式。
因为采用这种方式的坏处在于他不能站在高处俯瞰全貌，都是一点一点的往上堆砌，就是大家常说的摸着石头过河，最终会导致抽象不足，代码冗余，重构成本高，维护成本高，数据孤岛严重，子系统甚至是子模块业务互斥，向着恶性循环发展，最终项目变得越来越庞杂，无数的内耗产生。
大的项目，一定要从数据建模开始设计，一定是后端驱动，要认真仔细的思考每一个细节，先做抽象设计，然后具象到模块，再由模块具象到每一个实体、接口。
当这一切都设计好了之后，开始模拟数据流转，注意，此时还没有开始写一行代码。
数据流转通畅之后，剩下的编码只是水到渠成的事情，编码过程根本不重要。而这么做，JPA是最合适的。
但是，大部分土老帽认为程序设计是一件很low bee的事情，别笑，真事儿，因为他们认为不需要你来设计，他们自己就能设计好，你所要做的就是把他们“设计”好的东西用代码实现就好了。
他们最喜欢听的一句话就是：