基地商務艙：不好？

Question

我想創建我的基本業務類，像EntityBase，有一些共同的行爲，比如實現接口來跟蹤對象的變化（是否新款，IsDirty）和INotifyPropertyChanges接口。

但是很多人說這是一個壞主意，有一個基礎業務類和派生從它所有的業務對象。通常他們會說在實體類中有表示代碼是不好的。但我認爲這只是一個理論。在實踐中有什麼不好？他們說：自己嘗試一下。通常沒有更多的參數。

那麼你們怎麼看？是好還是壞？如果不好，爲什麼？請嘗試成爲一個實際的人，而不是理論。

Answer 1

這很糟糕。我們已經有這麼多年了，沒有什麼可以放在我們的基類中，它足夠通用，適用於所有的繼承類。

Answer 2

很多人訂閱的Single Responsibility Principle的想法，它說，一個班只能有責任的一個地區。通過將狀態跟蹤，渲染等構建到一個通用的基類中，您肯定會違反SRP。如果你的班級處理很多任務，它會有很多改變的理由。

Answer 3

從面向對象設計的角度來看，也許這不是最優雅的解決方案，但是如果你打算使用數據綁定，在基類中實現INotifyPropertyChanged通常是一個好主意。通過這種方式，您可以最大限度地減少必須在所有實體中實施它的負擔。

在更改跟蹤的情況下，如果您想將責任從基類中分離出來，您應該查看Unit of Work模式，儘管在.NET應用程序中指出實現更改跟蹤時非常常見不依賴於ORM。

Answer 4

我不認爲這是一定是壞事有一組接口和實現那些提供您在業務實體想要一些通用的功能，如果從這些派生不需要你的業務實體的接口基類基類。這爲您提供了實現的靈活性，同時提供了實現的便利。

例如，我有被應用到幾乎是我創建的每一個業務對象的IValidatedEntity接口。它要求業務對象實施一些驗證規則。但是，我的審計對象只是在內部創建的，我使用單元測試來確保無法創建無效的審計對象，因此這些類不會實現IValidatedEntity接口。

大多數從Web輸入AND包含來自XSSValidatedEntity類（實現IValidatedEntity接口）的字符串數據，但通過HTML解析器提供XSS檢查以防止將HTML注入數據庫。對於我的大多數類來說，這很好，但在那些想要允許有限（安全）HTML的情況下，我顯然不能從這個類中派生出來。

Answer 5

你所描述聽起來更像是一個演示文稿對象，然而IsDirty和是否新款也可以在域模型使用。在決定在基礎對象中包含什麼之前，您應該清楚地瞭解業務需求。一段時間關注業務對象，需求會有多少靜態？你是否掌握了所有規則來控制物體如何相互作用，這些規則是否會改變？如果他們改變，多久？這可能會帶來一些挑戰你

您可能會發現，根據不同的應用，你的工作的大部分應該來自實施業務流程，因此的CRUD功能架構。雖然很重要，但不是你努力的重點。換句話說，您的業務對象將支持業務流程的概念，而不包括IsDirty。您的數據訪問層可以專注於記錄的狀態並確定是否插入或更新數據。