比较
对象关系映射（ORM）框架允许我们从面向对象的语言访问关系数据库。多年来，我已经使用了几个用于Java的Hibernate / JPA，用于JavaScript的Bookshelf.js和Sequelize，仅举几例。我从来没有完全满意这些解决方案，因为这样或那样，他们不符合我的思维方式。最近，我尝试了MyBatis，呼吸新鲜空气！让我解释一下为什么。
域实体应该没有持久性问题
如果您遵循领域驱动设计，您可能会认同领域实体应该独立的想法。你不应该拖着一个持久性框架与他们。领域实体形成了六角形体系结构的内核，它只关注业务逻辑。你应该能够以任何你想要的方式站起来这个核心 - 通过构建新的对象或从数据库中检索它们，核心本身不应该在意。许多ORM污染这个核心与持久性的担忧，我不喜欢这一点。例如，Bookshelf强迫你使用Model对象定义实体，Sequelize使用sequelize.define（）。这会在实体内创建“隐藏的”属性和方法，教导他们坚持自己。我宁愿拥有专注于业务逻辑的纯Java / JavaScript对象，然后教导持久性框架坚持它们。
那么，这正是MyBatis所做的。实体是POJO，对持久性一无所知（参见这里）。相反，你教MyBatis如何保存和检索这些实体使用SQL语句和结果图（见这里）。对于琐碎的对象，你甚至不需要定义结果地图，MyBatis自动计算出来。
让我控制SQL
对于任何使用关系数据库的严重项目，您无法逃避学习SQL。大多数ORM试图通过提供更高级别的抽象来使您与SQL隔离。但是作为交换，他们强迫你学习一个新的API或一个抽象的查询语言。这些API /查询语言无论如何都会生成SQL，所以唯一的区别是你不知道它们是什么，直到你打开引擎盖。在很多情况下，我可以用单个语句编写的查询将以两个或更多语句生成，从而降低性能。现在我突然回到ORM并调整它以产生更高效的查询。有时候，API不够丰富，无法满足所需要的任何事情，无论如何，我都必须逃避SQL语言。为什么要这么麻烦？如果我必须知道SQL，为什么不直接自己写，直接优化呢？教学框架将结果映射到对象中要容易得多。
猜猜看，这正是MyBatis所做的 - 在这里看到结果图。它教MyBatis如何将查询结果映射到一个Transaction对象，并引用一个Account和一个Category。我最终得到更清晰和可理解的代码。
结论
我希望你能明白为什么我喜欢MyBatis。这将是我未来Java的默认ORM。不过，我还没有看到类似的JavaScript解决方案。如果有这样的解决方案，你会切换到吗？我很想听听你的想法。
技术讨论 & 疑问建议 & 个人博客
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议，转载请注明出处！
摘录自纳雷什·巴蒂亚
