在使用 MyBatis 開發項目時，Mapper 接口是為數據庫操作提供最直觀的方法，但在實現方式上，我們有兩種選擇：全注解模式和混合模式。那么，他們有什么區別，應該如何選擇？我們一起來討論一下。

一、全注解模式

全注解模式，兩個字：直接。不過在 Mapper 接口中加上注解，將數據庫操作直接通過 SQL 語句控制，想查詢就用?@Select，想插入就用?@Insert，完全是一樣的操作體驗。

實現樣例

這里有一個基礎的用戶操作 Mapper：

@Mapper
publicinterfaceUserMapper?{@Insert("INSERT INTO user (username, password, role) VALUES (#{username}, #{password}, #{role})")@Options(useGeneratedKeys = true, keyProperty = "id")voidinsertUser(User user);@Select("SELECT * FROM user WHERE username = #{username}")User?findByUsername(String username);@Update("UPDATE user SET password = #{password} WHERE id = #{id}")voidupdatePassword(@Param("id")?Integer id,?@Param("password")?String password);
}

優勢

• ? 文件構成簡單，文件自帶直觀性。

• ? SQL 語句在全注解模式下直觀且清晰，這種方式能夠減少錯誤的發生，尤其是在接口簡單、邏輯清晰的情況下。

• ? 適合小應用或數據庫表規模較簡單的場景。

不足

• ? SQL 語句直接嵌入代碼中，容易導致代碼臃腫：當查詢邏輯變復雜時，大量 SQL 會堆積在接口文件中，導致文件過長且難以維護。

• ? 擴展性差：復雜的查詢條件需要硬編碼在注解中，無法靈活調整，尤其對于需要動態拼接 SQL 的場景顯得力不從心。

• ? 團隊協作時難以分工：開發人員需要同時熟悉 SQL 和 Java，且 SQL 的變更可能需要修改接口文件，增加溝通成本。

二、混合模式

混合模式，是使用“接口聲明 + XML 配置文件”的方式實現。Mapper 接口直接定義操作類型，而 SQL 語句則存在于配置文件中

實現樣例

一個復雜旅游線路查詢 Mapper:

@Mapper
publicinterfaceTourLineMapper?{List<TourLine>?filterTourLines(@Param("destination")?String destination,@Param("minPrice")?Double minPrice,@Param("maxPrice")?Double maxPrice,@Param("minDuration")?Integer minDuration,@Param("maxDuration")?Integer maxDuration);
}

優勢體現在 XML 配置文件中：

<selectid="filterTourLines"parameterType="map"resultType="TourLine">SELECT * FROM tour_lineWHERE 1 = 1<iftest="destination != null">AND destination = #{destination}</if><iftest="minPrice != null">AND price >= #{minPrice}</if><iftest="maxPrice != null">AND price <= #{maxPrice}</if><iftest="minDuration != null">AND duration >= #{minDuration}</if><iftest="maxDuration != null">AND duration <= #{maxDuration}</if>
</select>

結構解讀

<select>?標簽

• ? 定義了一個?filterTourLines?查詢方法，與 Java 中的接口方法對應。

• ??parameterType="map"?指定了傳入的參數類型是一個 Map（常見場景中，通過?@Param?傳遞多個參數時，MyBatis 會將其轉換為 Map）。

• ??resultType="TourLine"?定義了查詢結果的返回類型為?TourLine?對象。

WHERE 1 = 1

這是一種防止 SQL 拼接錯誤的技巧，為后續條件拼接提供基礎，即使沒有后續條件，SQL 也不會因為沒有 WHERE 子句而報錯。

動態條件（<if>?標簽）

<if>?是 MyBatis 動態 SQL 的重要組成部分，用于判斷條件是否為 true，從而決定是否拼接該部分 SQL。

例如：

<iftest="destination != null">AND destination = #{destination}</if>

如果?destination?參數不為空，就會將?AND destination = #{destination}?拼接到最終的 SQL 語句中。

參數替換

每個條件中的?#{}?會被傳入的參數動態替換為具體值，保證查詢的安全性，防止 SQL 注入。

編寫技巧

SQL 拼接優雅性

使用?<if>?標簽時，可以避免在 Java 代碼中手動拼接 SQL，提高代碼的可讀性和維護性。

參數命名一致性

確保 XML 文件中的參數名稱與 Java 接口方法中?@Param?注解指定的名稱一致，否則會導致參數映射失敗。

靈活性

如果需要更多動態條件，比如基于某個字段的排序，可以在<if>標簽外部增加?<choose>?和<when>標簽實現更復雜的邏輯。

例如：

<choose><whentest="sortField != null and sortDirection != null">ORDER BY ${sortField} ${sortDirection}</when><otherwise>ORDER BY id ASC</otherwise>
</choose>

適用場景

這段動態 SQL 非常適合以下場景：

• ? 參數較多且查詢條件可能動態變化，比如多字段過濾、范圍查詢等。

• ? 查詢的復雜度較高，不適合直接寫在 Java 中，分離到 XML 更易維護。

優勢

• ??加強了 SQL 實現的優雅性：?復雜的查詢可以在 XML 文件中通過加入條件轉換，條件拼接更加靈活，避免硬編碼。

• ??分離關注點，降低耦合：?Java 和 SQL 各司其職，Java 專注業務邏輯，SQL 專注數據操作，改動時互不干擾。

• ??適合復雜查詢與大項目：?對于動態查詢需求較高的大型項目，混合模式顯得尤為重要，XML 配置文件支持強大的動態 SQL 功能（如?<if>、<choose>?等）。

不足

• ??學習成本較高：?需要同時掌握接口聲明和 XML 文件配置的語法，對初學者來說可能較難上手。

• ??文件分散，調試不便：?SQL 語句分散在 XML 文件中，可能導致維護時需要在多個文件間切換。

• ??開發速度稍慢：?相比全注解模式，混合模式的開發速度會稍有降低，尤其是在小型項目中。

三、如何選擇？

• ??如果你的項目規模較小，數據表結構簡單，查詢邏輯以基礎的增刪改查為主，可以選擇全注解模式。它能夠快速上手，開發效率高，適合對時間要求較高的場景。

• ??如果你的項目規模較大，查詢邏輯復雜且動態變化較多，建議選擇混合模式。它的靈活性和可維護性更強，能夠為復雜需求提供更好的支持。

• ??團隊協作時，混合模式的分離設計可以降低溝通成本，尤其對于 SQL 改動頻繁的項目。

無論選擇哪種模式，最重要的是根據項目需求靈活運用，選擇最適合自己團隊和業務的方式。