N 層アプリケーション設計のベスト プラクティスを見つけようとしています。私の UI が必要とするオブジェクトと、DB に永続化されるオブジェクトを設計するとき、私の同僚の何人かは、オブジェクトが同じものであることを提案しています。これは私には正しくないと感じており、最終的には、この決定に役立つベスト プラクティスのドキュメントを探しています。
編集: DBにあるテーブル(エンティティクラス)はUIで使用されるオブジェクトと同一であると言って、これを明確にしましょう
正直なところ、他のアプリケーションがデータ アクセス レイヤーと対話する可能性があることを考えると、なぜこのように設計する必要があるのか わかりません....または、それは単に私の無知または理解不足です。
あなたが提供できる文書、情報は大歓迎です。これらの概念をよりよく理解したいだけで、これらのパターンを実装するためのベスト プラクティスに関する適切な情報を見つけるのに苦労しています (または、見つけたものが目の前にあり、概説されていることを理解していませんでした)。 .
ありがとう、
S
まず第一に、DAO とデータベース エンティティは 2 つの非常に異なるものです。
今質問に。あなたが正しい。データベース エンティティはデータベース スキーマにマップされます。このデータベース スキーマは、データベース設計のベスト プラクティスに従い、正規化する必要があります。UI は、特定のエンティティからの情報を正確に表示することがありますが、多くの場合、複数のエンティティからのデータを集約形式で表示します。または、逆に、特定のエンティティのごく一部のみを表示します。
たとえば、UI に製品名、説明、価格、カテゴリ名、残りの在庫数、製品の製造元を表示することは理にかなっています。これらすべてのフィールドを含む永続的なエンティティを持つことは意味がありません。
一般に、ほとんどの「ベスト プラクティス」のコメントによると、はい、これら 2 つのレイヤーを分離し、個別のオブジェクトを作成する必要があります。
BUT: 非データベース オブジェクトに追加の機能がなく、マッピングが 1 対 1 のマッピングのみである場合、追加のオブジェクトを導入する必要はありません。だから、それは依存します。（いつものように ;-） ）。
導入されたオーバーヘッドがゲインよりも大きい場合は、追加のオブジェクトを使用しないでください。また、再利用性が第一級の目標である場合は、2 つのレイヤーを結合しないでください。これは、一部のレガシー アプリケーションには当てはまらない場合があります。