オブジェクトの変更を追跡するためのインターフェイス（IsNew、IsDirty）やINotifyPropertyChangesインターフェイスの実装など、いくつかの一般的な動作を持たせるために、EntityBaseなどの基本ビジネスクラスを作成したいと思います。
しかし、多くの人は、基本的なビジネスクラスを持ち、そこからすべてのビジネスオブジェクトを派生させるのは悪い考えだと言います。通常、エンティティクラスにプレゼンテーションコードを含めるのは悪いことだと言われています。しかし、それは単なる理論だと思います。実際には何が悪いですか？彼らは言う：自分で試してみてください。通常、これ以上の引数はありません。
それで、皆さんはどう思いますか？良いですか悪いですか？悪い場合、なぜですか？理論的ではなく、実践的な人間になるようにしてください。
多くの人が単一責任の原則の考え方に同意しています。これは、クラスは単一の責任領域のみを持つべきであるというものです。状態の追跡、レンダリングなどを共通の基本クラスに組み込むことで、確実に SRP に違反します。クラスが多くのタスクを処理する場合、変更する理由がたくさんあります。
悪いです。これは数年間ありましたが、継承されたすべてのクラスに適用できるほど汎用的な基本クラスに入れることができるものはありませんでした。
ビジネス エンティティがそれらの基本クラスから派生する必要がない場合、一連のインターフェイスと、ビジネス エンティティで必要ないくつかの共通機能を提供するインターフェイスを実装する基本クラスを用意することは、必ずしも悪いことではないと思います。これにより、実装の利便性を提供しながら、実装の柔軟性が得られます。
たとえば、私が作成するほぼすべてのビジネス オブジェクトに適用される IValidatedEntity インターフェイスがあります。ビジネス オブジェクトがいくつかの検証ルールを実装する必要があります。ただし、私の監査オブジェクトは内部でしか作成されず、単体テストを使用して、無効な監査オブジェクトを作成できないことを確認しているため、これらのクラスは IValidatedEntity インターフェイスを実装していません。
Web から入力を受け取り、文字列データを含むクラスのほとんどは、XSSValidatedEntity クラス (IValidatedEntity インターフェイスを実装) から派生しますが、HTML パーサーを介して XSS チェックを提供し、HTML がデータベースに挿入されるのを防ぎます。ほとんどのクラスではこれで問題なく動作しますが、限定された (安全な) HTML を許可したい場合は、明らかにこのクラスから派生できません。
あなたが説明しているのはプレゼンテーション オブジェクトのように聞こえますが、IsDirty と IsNew はドメイン モデルでも使用できます。基本オブジェクトに何を含めるかを決定する前に、ビジネス要件が何であるかを明確に把握する必要があります。ちょっとビジネスオブジェクトに焦点を当てますが、要件はどのくらい静的ですか? オブジェクトがどのように相互作用するかを管理するすべてのルールを把握していますか?それらのルールは変更されますか? それらが変更される場合、どのくらいの頻度で変更されますか? これはあなたにとって最も難しいことかもしれません
アプリケーションによっては、作業の大部分がビジネス プロセスの実装、つまり CRUD 機能のアーキテクチャの実装に由来する場合があります。重要ではありますが、あなたの努力の焦点ではありません。つまり、ビジネス オブジェクトはビジネス プロセスの概念をサポートし、IsDirty は含まれません。その後、データ アクセス層はレコードの状態に集中し、データを挿入するか更新するかを決定できます。
オブジェクト指向設計の観点からは、これは最も洗練されたソリューションではないかもしれませんが、データ バインディングを使用する場合は、基本クラスに INotifyPropertyChanged を実装することをお勧めします。このようにして、すべてのエンティティに実装する負担を最小限に抑えることができます。
変更追跡の場合、その責任を基本クラスから分離したい場合は、Unit of Workパターンを確認する必要がありますが、そうでない .net アプリケーションで指摘したように、変更追跡が実装されているのを見るのは非常に一般的です。 ORM に依存します。