面向方面編程在面向對象的世界突破規則？

Question

當我在asp.net mvc網站項目上工作時，我調查了不同的驗證方法。其中一些是DataAnotation驗證和驗證塊。他們使用屬性來設置驗證規則。就像這樣：

[Required] 
public string Name {get;set;} 

我被搞糊塗了這種方法如何使用SRP（單一負有責任的原則）從OOP的世界結合。我也不喜歡業務對象中的任何業務邏輯，我更喜歡「糟糕的業務對象」模型，但是當我用真實需求的驗證屬性來裝飾業務對象時，它們變得醜陋（具有很多屬性/帶有本地化邏輯和等等）。

想法與屬性真的很簡單，但在我看來，驗證裝飾應與對象分開。我不確定將驗證規則分離到xml文件或另一個對象的方法，也許這是一個解決方案。

AOP的另一個不好的方面 - 單元測試這樣的代碼的問題。當我使用自定義屬性修飾某些控制器動作時，例如在動作之間導入/導出TempData或初始化一些必需的服務時，我無法編寫適當的單元測試來測試此操作。

你認爲這些屬性不會破壞srp，或者你忽略了這一點，並認爲它最簡單，不是最糟糕的方式嗎？

P.S.我讀了一些喜歡的文章和討論，我只是想把事情按正確的順序排列。

P.P.S.我的「流利」英語遺憾：=）

編輯 我認爲這是打破規則「和醜陋的將是這樣的場景： 如果在驗證具有一定的業務規則 - 例如用戶必須有唯一的電子郵件在系統中，您應該驗證用戶輸入在應用程序中拋出所有圖層，因此當您編寫自定義屬性以檢查此數據時，業務對象將與您的數據層throw屬性相關聯。

Answer 1

AOP本身不會破壞任何SOLID規則，特別是SRP。

如果您在業務對象內使用UI驗證屬性，那麼它肯定會破壞SRP。但是如果你在UI和BL之間的界面中使用特殊的UI類，那麼所有的東西都滿足SRP。

Answer 2

我相信驗證規則適用於您用於UI的模型對象。實際上，他們用一組約束來描述每個數據，這些約束定義數據的值是否可接受。

我也一直在努力，但我相信裝飾方法是好的，因爲你設置它並忘記它：如果你有外部驗證，那麼你有可能忘記應用驗證，並結束與無效的數據。

我曾經使用驗證getter和setters，這是一個可怕的想法。

有一種簡單的方法將問題分爲不同的地方：使用部分類。像通常那樣定義類，但將其設置爲partial，然後使用單獨的文件來定義字段及其裝飾：它們將合併到類中，而不會亂拋垃圾代碼，因爲它們的細節太多。