设计理念

此工具可能会引发一些哲理性问题， 因为该工具是更侧重于数据库表，而不是实体类。 我们将采取几个段落来谈论这种做法。

首先，这个工具做什么。我们不是在做任何有关项目应该或不应该是结构化这种说法的。 在一般情况下我们支持富实体类， 但创建一个富实体类和是否应该坚持这种模式完全不是一码事。

如果您特定的设计理念是实体类驱动所有的决策，数据库设计是屈从于实体类， 那么这个工具 - 和MyBatis本身 - 可能不适合您的应用程序。 在这种情况下，我们建议您认真考虑 Hibernate - 他可能更贴近您的应用程序和设计理念。

但并非所有的项目都适合这种模式。很少有真正的企业级应用程序会这么做。 MyBatis对那些将数据库表设计和实体对象设计看做一样的项目有很大的帮助。 MyBatis不是对象关系映射，并且不会尝试去持久化对象。所以他着眼于应用开发人员编写SQL和数据库表进行交互。

在大型或企业级的项目，其中的许多因素是很常见:

  • 数据库设计往往是从 OO 实体设计一个单独的功能（有单独的管理）
  • 数据库设计者没有 OO 工具 （比如继承），所以他们不从 OO 考虑。
  • 应用程序设计人员并不能完全控制数据库表的最后形式。 例如，在应用中适合存在于一个对象的数据，在数据库中可能被分成几个表。
  • 数据库设计最终和OO设计的完全不同，从而导致表和对象之间的明显不能匹配。

从这些主要的指标来看，对您的应用来说 MyBatis 是一个非常不错的候选工具，MyBatis Generator 可以在这类项目起到重要的影响。 那么，在这种情况下应该如何使用MyBatis?

数据访问对象(DAO)模式仍然是一种主要的模式。MyBatis Generator可以生成一组基本的和每个表对应的对象。 生成的代码是和事务无关的。这意味着如果在一个事务中涉及多个表参与，可以很容易的扩展生成的代码。 或者您可以创建另一个DAO（或服务方法），更紧密地匹配实体对象的持久性需求，并可以再一个事务中使用一个或多个生成的对象。

举个例子，考虑一个典型的 Order 对象，典型的标题和细节的问题。 在某些环境中这种对象将保存到至少四个表 - 两个关键表、"标题"表和"详细信息"表 (再次声明，我们不做任何种类的关于这是否"正确"的语句设计，只在陈述一个事实)。 您的应用程序还应与 Order 对象进行交互, 并且可能在某个地方（在OrderDAO 或者在一个Service对象）存在一个saveOrder(Order order)方法 该方法将与所涉及的4个表生成的代码进行交互。

在这种情况下，代码生成器给我们带来什么? 有以下几种:

  • 重用（复用） - 很可能是一些表将需要从不同的DAO或者Service方法访问。 为每个表创建一个 DAO 可以促进重用和应用程序内的一致性。
  • 数据库抽象 - 服务层通常在应用程序中定义持久性。这些方法可以很快稳定。 随着数据库设计的发展：
    1. 代码可以很快的随着表的改变而重新生成
    2. Service方法可以根据需要修改
    3. 更高层的应用程序保持不变
  • 开发者的效率 - 生成基于表的DAO是很快速、可重复和无差错的。 开发人员可以专注于对象持久化和可能需要的复杂的联接查询。
  • 更少的缺陷 - 因为所有应用程序中最繁琐和最容易出错的部分（获得SQL匹配的对象）是自动化的。