2013-03-05 127 views
3

我想我錯過了一些非常明顯的東西,但是對於域對象和它們通過存儲庫的持久性存在很多分歧,因此很難在此得到明確的答案。沒有Getters的DDD對象持久性

假設

  • 我已經建立了有我的解決方案中的任何其他 組件沒有依賴性爲DDD只有一個明確的根 聚集態純域模型。

  • 我有一個域特定的存儲庫,它保留了由服務層調用的根 聚合。

  • 內部倉庫使用EF與 其子

一起堅持的對象。如果避免暴露干將(絕對不是制定者),那麼請問我的倉庫可以訪問該對象的狀態爲了實際堅持下去。

選項??

  1. 依賴注入到域模型(DDD氣味??)

  2. 吸氣劑只(DDD氣味??)

也有是牽引對象出來的反向問題DB。通過構造函數初始化似乎是唯一可能的候選者。

回答

2

ORM可以通過反射獲取對象內的數據。例如,NHibernate has various access strategies表示允許映射類僅具有不帶getter或setters的私有字段的屬性。我認爲EF應該有類似的設施。

+0

我可以這樣做,但它感覺有點奇怪 – csherriff 2013-03-05 07:12:17

+0

謝謝eulerfx ..進一步閱讀後,我認爲公共getter /私人setter的想法可能是最好的選擇在這裏..至少直到我解決如何處理整體EF5無知的事情。老實說,我在推動純粹的DDD實施方面有點過分..我想它值得明確地思考問題雖然 – csherriff 2013-03-06 01:26:10

1

正如eulerfx所述:由於您使用的是ORM,因此您必須使用提供的內容。

我永遠不會樂意使用ORM,所以我的經驗有點有限,但它確實似乎是一個問題,因爲ORM以某種形式進入對象模型。在某些情況下,它迫使你以特定的方式設計你的課程。

這就是說。爲了堅持一個對象,你需要它的狀態。爲了保溼一個物體,你需要提供它的狀態。這一點沒有辦法。如果你的工具需要getter和setters,那就這樣吧。

您可能會有一些狀態對象被您的對象暴露/消耗,即使其意圖更清晰一些,但它只是移動問題---但它可能更好:)。

即使發生事件,事件也包含狀態,必須將其應用於對象以使其恢復到其最後狀態,或者可以使用與狀態對象完全相同的快照。

公共獲得者和接受者有些開放濫用,但事實就是這樣。

+0

我很高興使用EF5生成的實體用於持久性目的,因爲這些只存在於in我的倉庫程序集。我認爲如果DDD聲稱需要純域名彙編代碼,那麼他們必須對此問題有一些解決方案。最小侵入性的方法似乎只是將IRepository注入到我的根集合中 – csherriff 2013-03-05 07:08:36