交易腳本是反模式？

Question

那麼有關於NoSQL數據庫的交易腳本的類似主題，但這一個是關於一般模式。根據我對交易腳本的瞭解，它不是面向對象的。它基本上是程序性的代碼，儘管它可以在代碼的每一行中使用對象。

更好的解決方案是使用領域模型，而不是使用活動記錄或數據映射器與工作單位/身份映射/延遲加載/查詢對象等。交易腳本可能易於使用，但它確實是程序編程，因此在面向對象的世界中應被視爲反模式。

您認爲如何？你同意交易腳本是反模式嗎？或者你真的有辦法設計一個面向對象的交易腳本，而不是僞裝的程序？我懷疑這是可能的，但。

Answer 1

交易腳本絕對是不是反模式。

從我發現的事務腳本來看，它根本不是面向對象的。

你是對的，事實上並非如此。然而，這個事實並沒有使它成爲反模式。雖然它是一種程序性方法，但事實上，它仍然在一系列業務邏輯體系結構模式中佔據了正確的位置 - 您只需知道在哪種情況下使用它是最佳實踐 - 而在這種情況下則不然。簡而言之：如果您的問題域非常簡單，那麼在您的業務邏輯中使用更復雜的模式不值得。

或者 - 爲Fowler寫道：

當使用它

事務腳本的榮耀是它的簡單性。對於只有少量邏輯的應用來說，以這種方式組織邏輯是很自然的，並且它在性能或理解上涉及很少的開銷。

您可能會想到的反模式稱爲Anemic Domain Model。這是當你打算和認爲你正在建設一個域模型的情況下 - 因爲你的問題域是足夠複雜， - 但實際上你在交易中腳本結束了 - 因爲糟糕的代碼組織的/弱OO技能。

Answer 2

這是不是反模式。實際上，大多數企業應用程序（我所見過的）都使用事務腳本，而不是豐富的領域模型模式。

活動記錄您提到的模式只有在您將域實體與持久性存儲聚合（RDBMS表）進行一對一映射時非常方便。

數據映射器類似於ORM（休眠和朋友）。如果您的業務邏輯駐留在域實體中，則這些實體必須自行變異。在我看來，這種結合邏輯使狀態變化（這是你使用ORM時固有的）與狀態本身。從外部查看您的域模型並將您的業務邏輯放入服務（交易腳本）更爲簡單。另外，如果您的業務邏輯卷很大，那麼在跨域實體分散時就很難找到相關的代碼（就像將您的事務腳本混合在一起）。

但是，由於您可以（也應該）將您的服務分解爲獨立的高度連貫的「程序容器」，因此您不必完全採用程序化方法。