# 設計理念 此工具可能會引發一些哲理性問題， 因為該工具是更側重于數據庫表，而不是實體類。 我們將采取幾個段落來談論這種做法。 首先，這個工具做什么。我們不是在做任何有關項目應該或不應該是結構化這種說法的。 在一般情況下我們支持富實體類， 但創建一個富實體類和是否應該堅持這種模式完全不是一碼事。 如果您特定的設計理念是實體類驅動所有的決策，數據庫設計是屈從于實體類， 那么這個工具 - 和MyBatis本身 - 可能不適合您的應用程序。 在這種情況下，我們建議您認真考慮 [Hibernate](http://www.hibernate.org) - 他可能更貼近您的應用程序和設計理念。 但并非所有的項目都適合這種模式。很少有真正的企業級應用程序會這么做。 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匹配的對象）是自動化的。