服務層驗證與域對象驗證;潛在的「濫用」域對象？

Question

我見過很多書和文章的例子，說要在你的服務層中加入驗證碼。保持域對象「啞」（又名純POCO），並處理域對象可能在服務層中執行的所有驗證。

服務層負責這麼多似乎（或至少可以）;用戶身份驗證，角色身份驗證，IoC（記錄器，錯誤處理程序等）的腳本依賴對象，編寫域對象腳本，編寫存儲庫腳本以及將域對象傳入和傳出存儲庫......嗖！

不在服務層中創建所有這些規則對您的域對象構成嚴重威脅？例如，一些程序員決定直接針對你的域對象編寫消費代碼，並完全繞過服務層呢？那會很糟糕，但是一個可信的情況。

如果您打算在服務層中承擔很多責任，包括所有域對象驗證，有沒有辦法「保護」您的域對象是否有人試圖直接編寫它們？例如，也許某種方式你的域對象現在他們沒有被某個客戶端使用（在這種情況下，服務層？）。

良好的設計讓我覺得域對象應該對誰叫他們以及他們如何被調用一無所知。

如果沒有辦法「鎖定」域對象，那麼爲什麼有太多的文章，書籍等建議將服務層中的域對象驗證放到路上？我想通過採取防禦性編程的立場，你應該建立你的域對象是防彈的，並依靠你的服務層來獲得簡單的代碼層來轉發和接收UI和BAL/DAL之間的請求。

有沒有人有過一些真實的項目經驗，他們已經繞過他們的服務層的人濫用了他們的域對象？

Answer 1

他們是2種不同的設計理念。富域模型與貧血域模型。

簡短的回答是肯定的，你可以阻止直接訪問你的域對象。

您可以通過多種技術這樣做：

1）可以使所有面向公衆的域對象的不可變的（即你不能僅通過具有唯一的公共方法是干將更改數據）。所有修改對象的方法都可以被保護或者是私有的，所以只有正確打包的服務才能訪問它們（至少在Java中）
2）你只能向外部開發人員公開單獨的類 - 所以如果你有一個Person域類可以有一個你傳遞的PersonInfo類，它除了包含信息之外什麼也不做。
3）您應該向應用程序使用者公開一個一致的API。你基本上阻止他們繞過你的服務層。

Answer 2

我想你可能會誤解一個POCO的目的。據我瞭解，POCO不是隻有屬性和屬性的貧血域對象。而POCO根本不是綁定到框架或複雜的繼承模型。該對象是靈活的，只關心它在域中的角色。