设计哲学与致歉

这个工具可能会引发一些哲学问题，因为该工具更注重数据库表而不是域模型。我们将采取几段谈论这种方法。首先，这个工具可以做到这一点。我们没有就项目应该或不应该结构化做出任何形式的陈述。一般来说，我们是富有领域模型的坚强支持者 - 但创建一个丰富的领域模型与回答这个模式应该如何坚持的问题是截然不同的。如果您的特定设计理念是域模型驱动所有决策，并且数据库设计服从于域模型，则此工具 - 和MyBatis本身 - 可能不适合您的应用程序。在这种情况下，我们建议认真观察Hibernate - 它可能更符合您的应用设计和理念。

但并不是所有的项目都符合这个范例。真正的企业级应用程序很少。MyBatis可以在数据库设计被视为与域对象设计相同的项目中获得巨大的帮助。MyBatis不是一个对象关系映射器，并不会透明地持久化对象。因此，应用程序开发人员编写SQL以与数据库表进行交互。在大型或企业级项目中，许多因素很常见：

• 数据库设计通常是与OO域设计的独立功能（独立管理）
• 数据库设计师没有OO工具（如继承），所以他们不以OO的方式思考
• 应用程序设计人员无法完全控制数据库表的最终形式。例如，似乎适合应用程序的一个对象的数据可能会被拆分成数据库中的几个表。
• 数据库设计通常与OO设计完全不同，导致表和对象之间的显着不匹配。

这些因素是MyBatis是您的应用程序的良好候选工具的主要指标，这是MyBatis Generator可以产生重大影响的项目类型。那么MyBatis在这种情况下应该如何使用呢？数据访问对象（DAO）模式仍然是主要模式。MyBatis Generator可以生成与每个单独表格匹配的一组基本对象。生成的代码是事务中立的。这意味着如果事务中涉及多个表，则很容易将生成的代码扩展为添加事务属性。或者，您可以创建另一个与域对象的持久性需求更匹配的DAO（或服务方法），并在单个事务中使用一个或多个生成的对象。
例如，考虑一个典型的Order对象 - 典型的header / detail问题。在某些环境中，这样的对象将被持久化到至少4个表中 - 两个关键表，一个“标题”表和一个“详细”表（再次，我们没有提出任何关于这是否是“正确的”设计的陈述，只是说一个事实）。您的应用程序仍应与Order对象进行交互，并且在某个地方（在OrderDAO或服务对象中）可能存在saveOrder（Order order）方法。该方法将与所涉及的4个表中的每一个的生成代码进行交互。在这种情况下，代码产生了什么？几件事情：重用 - 可能需要从多个不同的DAO或服务方法访问某些表。1、为每个表创建一个DAO可以促进应用程序中的重用和一致性。数据库抽象 - 服务层通常在应用程序中定义持久性。2、这些方法可以很快地稳定下来。随着数据库设计的发展：

• 随着数据表的更改，代码可以快速重新生成
• 可以根据需要修改服务方法
• 应用程序中的较高层保持不变

3、开发人员生产力 - 基于生成表的DAO是快速可重复且无错误的。开发人员可以专注于Object持久性，如果需要，可以使用复杂的连接查询。4、更少的缺陷 - 因为任何应用程序中最繁琐和容易出错的部分（使SQL与对象相匹配）都是自动化的。
原文：Philosophy and Apology

相关阅读：

MyBatis Generator (MBG) 代码生成器简介

MyBatis Generator 代码生成器 快速入门指南

MyBatis Generator XML 配置文件参考

运行 MyBatis Generator 后的任务

运行MyBatis Generator

MyBatis Generator中的新功能

SSM框架——使用 MyBatis Generator 生成代码，包括：Model、Dao、Mapping

从源