這個ORM模式叫什么

Question

我已經習慣了像JPA這樣的框架來在數據庫行和Java對象之間進行對象關系映射。

但是，在我的公司中，我們為ORM使用專有框架，該框架不使用實體類來表示實體，而僅使用java.util.Map類將數據庫列值映射到其名稱。

通常，此類地圖還可以用作表示層的模型以呈現表單。 再次發布表單會將參數作為映射注入到處理程序方法中。 這是2000年代初期的舊框架。

甚至以為在實體類上使用映射會聞到過時和反模式的味道，我實際上喜歡此模型的“動態”性質。 您可以輕松地將任何數據添加到業務邏輯層中的地圖上，然后再將其傳遞到表示層，並且只需更改模板本身，它就成為表單的一部分。 如有必要，它允許您使用任何內容擴充任何實體。 如果您必須在特定條件下顯示特定字段的特定通知，這最終將很有用。 您只需檢查條件，必要時將通知添加到地圖，如果地圖中存在通知，則在模板中進行渲染。 如果使用實體類，則需要使用屬性來重構實體類接口，該屬性甚至不是實體的真實屬性。 業務邏輯充滿了這些特殊條件，並且它們在不斷發展。

這是危險的想法嗎-我是否願意采取反模式？ 還是有理由在復雜的業務領域中使用這種模式，並且這種模式有名稱嗎？

Answer 1

我不知道適合您描述的模式，但是在實體類上使用Map也會有缺點。

您可以輕松地將任何數據添加到業務邏輯層中的地圖上，然后再將其傳遞到表示層，並且只需更改模板本身，它就成為表單的一部分。

您所看到的優勢意味着您永遠無法確定Map處於哪種狀態。 如果通過服務1加載實體，則映射可能包含一些值。 如果您通過另一個服務2加載同一實體，則該實體可能不包含某些值。 Map的狀態是特定於用例的。

由於您正在使用Map因此從客戶端的角度來看，這也意味着每個屬性都具有相同的類型，例如Map<String, Object> 。 因此，如果您在代碼中看到一個實體映射，則還必須知道它具有哪種類型。 在不知道例如很難計算總訂單的情況下。

只要您是唯一處理該代碼的人，並且知道所有Map狀態，您就會認為它是靈活而快速的。 如果一段時間未使用此類代碼，則可能會忘記Map可能具有的不同狀態。 然后，您必須遍歷每個用例的整個代碼，以查看是否有一段代碼添加或刪除了屬性或僅替換了屬性類型。

因此，請嘗試從文檔角度考慮該設計。 專用實體類的最大優點是它被命名。 您可以給一個班級起一個名字，也就給它一個含義。 例如

public class PlacedOrder { ... }
public class Refund { ... }

您也可以輕松地將javadoc添加到該類中，以提供有關該類在您的上下文中的含義的更多詳細信息。 這通常稱為Ubiquitous Language 。 我經常只使用術語“域語言”，因為它說起來更容易。

以我的經驗，這種設計通常會導致系統難以維護。 剛開始時，代碼庫很小，所以您真的很快。 但這並不令人驚奇，因為您經常通過不應用干凈的代碼原理來節省文檔時間。

由於編譯器無法檢查類型，因此僅在運行時會發現類型問題。 這意味着您必須創建一個強大的測試工具 ，因為測試還必須發現編譯器可能報告的錯誤。 或者，您只是開發嘗試和錯誤的方式，但這不是我的方式，也不會讓我滿意。