博客评论 - 其实，我更喜欢写SQL - OSCHINA

techwiz

11/27 17:51

如果项目是你一个人写，你喜欢怎么写都无所谓。
如果是团队项目，你用自己的喜欢来选择，没有考虑团队技术栈，协作效率，维护性，新成员学习成本等系列问题，那只能是项目的悲哀了

贝

贝克街的天才

11/27 18:03

mybatis 一样约束不了规范，哪怕上JPA 也没法控制别人不要写原生SQL，更控制不住写的满天飞。至于你说的协作效率，维护性，新成员学习成本，你可以具体指出哪里不行。

贝

贝克街的天才

11/27 18:07

不好意思，网卡了一下，不是有意刷屏的

techwiz

11/27 20:49

你好！@贝克街的天才并不是说哪里行或不行。我理解你的意思。 mybatis倡导的的是原生SQL映射，hibernate讲究的是数据表实体模型映射。它们把java的orm分别向两个方向发展。因此也就有了不同的应用场景。也出现各种类mybatis，类hibernate框架。理解它们的特点，才能在不同的场景中找到最合适的框架。为什么要用它们，它们也是不能百分百约束开发者编写规范的。这句话似乎没有错。好的框架都提供一定自由度，以应付特殊的情况，这也是不能完全约束的根源；但是绝大多数情况下，它们都有合理的编写使用规范，可以不遵循，但是想要用好它的人，应当要遵循。在团队里面，针对具体项目的规范，比如SQL编写等，需要再次约定。框架保证了即使程序员没有遵守团队的约定，但遵循框架的使用规范，程序会在统一规范的范围内。包括一些框架的代码生成，标签规定，这既是提高生产效率，又是统一规范。我并没有说MagicDBUtils不行，我没有研究过这个框架。我要说的是技术选型与实际应用之间的问题。写原生SQL没有问题。但是在许多团队项目中，实体框架，类似hibernate或其他JPA框架，往往是更优的选择。这些框架提供了更高的抽象层次，减少了手动编写SQL的需求，也提高了开发效率和代码的可维护性。我是根据主题表达个人经验，如果认为这些说法是错误的，就请忽略它吧。