這是一個貧血的領域模型？

我想構建我的第一個CRUD應用程序，但我不明白我是否應該使用包含getter和setters的對象分開。這是一個貧血的領域模型？

考慮到我們有Zend Framework Quick Start tutorial含模型結構：

網關
DataMapper的
域對象（模型類）

如果域對象（如呈現在Zend快速入門教程）只包含getter和setter，是否是反模式？從某種意義上說，我們正在不斷地將域對象與事務腳本分開？

請指教。

來源

2011-05-03 MEM

域對象是從軟件的業務邏輯中分離出來的。這是procedural programming的重要思想。

然而，這種模式被認爲是一些開發商反模式的候選人，這意味着這可能是一種無效的做法。

事實上，你可以考慮缺點

你的模型是少的表現，getter和setter方法是不是真的很好的描述模型
代碼更難重用，你會得到你的事務中dublicated代碼腳本
，你必須使用其隱藏實際的數據結構（所以也許不是真的OOP）
總有實體的全球訪問包裝

我認爲最有意思的一點是，領域模型的對象無法在任何時候保證它們的正確性。因爲它們的變異發生在分離的層中。

我也在使用zend框架開發CRUD應用程序。邏輯和數據之間的清晰分離真的很棒，但是當你進步的時候，你會意識到圖層和映射器的數量越來越大。嘗試儘可能重複使用您的代碼並避免發佈。

來源

2011-05-03 11:35:32

您的問題很好地闡明瞭：「爲什麼貧血區域模型是反模式」。但是它並沒有回答我的問題提出的另一個問題：在表格數據網關/數據映射器設計模式上 - 就像Zend Framework快速指南教程中介紹的一樣 - 我們是否也在處理反模式案例？ – MEM 2011-05-03 11:41:31

沒有資源將此模式定義爲反模式，至少我找不到一個模式。我指出一些開發人員將其視爲反模式的候選人。所以一方面你有清楚分離的好處，另一方面也有缺點。你看到有很多「對比」，這意味着它更像是一種反模式 – 2011-05-03 11:46:10

「你的模型不那麼富有表現力」 - 當你建模一個CRUD應用程序時，模型不需要在獲取/設置旁邊表達也許有些驗證。「代碼很難重用」 - 再次CRUD通常很簡單，並且正確的框架背後並不是一個問題。「模型的對象不能保證它們的正確性」 - 如果你期望從你的域對象得到這個，那麼你需要使用DDD開始設計它們（將它們分組成集合，充當一致性邊界等），在這種情況下有一個貧血域模型IS和抗百通。 – 2011-05-03 13:09:13

如果您試圖構建一個真正的領域模型（也稱爲領域驅動設計的領域模型）並最終得到僅具有狀態且沒有行爲的實體，那麼貧血領域模型僅僅是一個反模型。

對於簡單的CRUD應用程序來說，貧血區域模型可能是一種最佳實踐，尤其是當您的框架使您的工作變得非常簡單時。

請參閱Martin Fowler的文章Anemic Domain Model以及Greg Young's Article。

來源

2011-05-03 11:14:38

那麼，我們對領域模型有兩個意義？一次感覺，Zf快速教程感，告訴我們：1）領域模型（通過引用一個模型類，代表一個領域對象？）2）領域模型的領域驅動設計模式？我在問這個問題，因爲在提供的鏈接上，你可以看到一個聲明，那個getter和setter類首先被認爲是「Domain Model」，後來被認爲是「Domain Object」... – MEM 2011-05-03 11:35:41

對象是從模型創建的 – 2011-05-03 11:41:08

@ArtWorkAD：嗯......所以，我們不應該說：「域模型是指代表一個域對象的模型類」，但我們應該說：「域模型作爲一些模型類在MVC的M部分中的類），這些類可以響應創建「域對象」。是嗎？Arrrhhh !!請耐心等待:)） – MEM 2011-05-03 11:46:58

這是一個貧血的領域模型？

回答

相關問題