服務層DTO - 大型複雜交互式類報表對象

Question

我有一個會議對象，它構成了一個調度系統的基礎，其中gridviews用於顯示重要信息。這是爲了安排員工參加會議，並讓員工查看已安排的內容。

我一直在嘗試遵循DDD原則，但我很難知道從服務層傳遞到系統的顯示區域的內容。這是因爲時間表可能很大，並且實際上由系統的許多不同元素組成。例如。客戶名稱，地址，案例信息，組等等，這些都是會議安排人員作出決定所需要的。

除此之外，調度程序需要更改此調度內的值，並將其傳遞迴服務層（例如，從下拉菜單中分配員工，也許是更改組等）。所以，這些信息並不是真正的「只讀」 - 它需要與之交互。即。這不僅僅是一個報告。

我們當前的方法是從SQL中填充一個扁平化的「計劃對象」，它由不同領域對象的小部分構成。這是一個相當複雜的查詢。在進行更改後，會將其傳回服務層，服務將檢索有問題的域對象，並使用來自DTO的信息在域對象上激發業務方法。

我的問題是，這是正確的方法？即。繼續從SQL生成大型自定義對象，然後從服務層傳遞到表現層對象，這些對象與View Models很相似？

UPDATE由於答案

爲了給量實體的想法/聚集參與的關係。 （這是一個混淆的例子，這樣的關係在這裏是重要的事情）

• 客戶端是一個默認組

• 客戶端有一個開放的情況下，但許多封閉

• 案例有很多會議

• 會議有許多分配員工

• 相約ING有很多理由

• 會議能獲得計劃到不同的組

• 員工可以與許多組相關聯。

該計劃需要加載屬於與該員工處於相同組中的患者的未決病例的所有會議。

調度程序可以查看客戶名稱，客戶地址，個案信息，MeetingTime，MeetingType，MeetingReasons，scheduledGroup（s）（showstrail），分配的員工（也包含隱藏的員工ID）。

可編輯欄位分配員工下拉菜單和預定組。

• 時間表最多可以有兩百行。
• DTO即將從WCF下來，所以域模型該服務層上方訪問，並且不低於。
• 領域模型的業務電話，基於傳回DTO值服務利用，以及資料庫處理插入/更新。

所以，我想更新中，使用查詢來填充它包含了所有上述的可接受傳遞下去作爲一個合併的DTO對象？如果不是，你會如何處理它？ （給服務層一些示例調用，並解釋了一些關於如何設想ORM獲取數據的方法，以記住性能）

Answer 1

在服務層及其下面，我將對待每個實體（請參閱DDD中的聚合根）相對於它的事務邊界是分開的。即即使您可以在同一UI視圖中更新客戶端和案例，最好事務性修改客戶端並修改案例。您在一次交易中嘗試修改得越多，您就可以與其他用戶發生衝突的次數越多。

雖然你的日程安排是很大，並且可能含有大量的對象，服務層應與每個實體（聚合根）單獨處理一遍，然後捆綁在一起，成爲一個新的視圖模式。令人遺憾的是，在棕色領域項目中，SQL中可能存在大量邏輯，而大規模多表連接可能會使得難以重構更多的原子查詢來完成所需的任務。以數據爲中心的「以數據庫方式處理所有事情」的舊式學習觀點違背了DDD的一切。

因爲DDD是一個設計思想和模式的集合，而不是一個方法論或架構，聽起來現在嘗試將您當前的應用程序變成以DDD應用程序爲中心的設計時已經太晚了。這聽起來好像您的當前應用程序在以數據爲中心的視圖中非常根深蒂固。

如果目前所有內容都通過一個整體大塊中的圖層傳遞，那麼最好保持這種風格，並將這些大塊大塊暴露給其他團隊中希望使用它們的人，以供在他們的新應用。您可能可以放置某種視圖模型緩存（有點像CQRS中的緩存視圖模型元素）。

我個人認爲，以數據爲中心，歸一化數據的應用程序有他們的日子（他們提出在20世紀70年代感覺，當硬盤空間是昂貴的），所有的應用程序應該向更現代的做法是移動。實際上，只有當遺留系統癱瘓時，利益相關者通常會拿出現金來尋找替代方案（通常在將每個最後的服務器填充到RAM之後）。可能或最好說服他們一次重構小部分內容。