ビジネスロジックエンティティとデータアクセスレイヤーエンティティ
プロジェクトの構成を考えています。これらのレイヤーを分離するために、BLとDALの間で異なるエンティティークラスを使用することは良い習慣かどうかと思います。
私はエンティティクラスが別のプロジェクト/パッケージにあるプロジェクトに取り組んできました。次に、BLとDALは同じエンティティを使用しました。
しかし、より良いアプローチは、すべてのレイヤーとそのアセンブリのエンティティクラスを定義することだと想像できます。そのようなアプローチの客観的な長所と短所は何ですか？
BL、エンティティおよびDAL
BLの目的は、ドメインエンティティで機能するドメインロジックを実装することです。これらのエンティティの定義はビジネス主導です。
DALの目的は、ドメインエンティティの永続性を整理することです。アイデアは、データアクセスとデータベースの醜い詳細を上位層から隠すことです。うまくできていれば、表面下のデータベースを変更しても、上位層は変更しないでおくことができます。
当然のことながら、ドメイン エンティティは両方のレイヤーで共有されます ：BLはドメインアクティビティを実行する必要がありますが、DALは永続性を整理する必要があります。
BLとDALを分離しますか？
コンポーネントを分離することは、一般的に非常に良い考えです。ただし、レイヤーは独立したコンポーネントではありません。レイヤーは、関連するクラスの論理的なグループです。
事実であれば、レイヤーダイアグラムを再描画して、エンティティを含むBLとDALの間のレイヤーを想像することもできます。そして突然、レイヤーはクリーンで分離されたように見えます。
代替案は何ですか？
異なるレイヤーで2つの異なる種類のエンティティを使用する代替案を提案します。したがって、BLには適切なドメインエンティティが含まれます。また、DALには中間データアクセスエンティティがあります。
ここで、この完璧なスキームを実装するとします。次に、BLエンティティとDALエンティティをどのようにリンクしますか？どういうわけか、これらはデータを同期するためにお互いを知る必要があります。つまり、とにかくレイヤー間の強い結合を持つことになります。それはそれほど明白ではないというだけです。
クラスでエンティティを定義し、BLとDALで同じエンティティを使用します。この設計により、エンティティを時々変更することに起因する時間とバグを節約できます。
プロジェクトが単純で単一のデータソースを使用している場合、ビジネスロジックとデータアクセスレイヤーが同じエンティティクラスを使用する同じエンティティクラスを使用することは理にかなっています。複数のデータソースを処理していて、ビジネスロジックが複数のデータソースを処理し、多くの検証とデータ転送を処理している場合。個別のオブジェクト、つまりビジネスレイヤーのデータ転送オブジェクトを使用できます。これにより、1回の呼び出しで1つのシンプルなDTOをプレゼンテーションレイヤーに与える柔軟性が得られます。