.net - ビジネス オブジェクトとしての LINQ エンティティ - 賛否両論

Question

Visual Studio (sqlmetal) によって生成された dbml ファイルには、データベース テーブルにマップされたエンティティが付属しています。これらのクラスはドメイン モデル クラスとして使用するのに適していると思いますか? それとも、それらを避けて、データ アクセス レイヤーのみに分離する必要がありますか?

ありがとう

Answer 1

ほとんどの場合、エンティティ オブジェクトと SQL の記述の間の便利なレイヤーはDALです。LINQ の全体的な目的は、これまで可能だったよりもはるかに表現力豊かな構成を DAL で使用できるようにすることです。

GetCustomersByLastName(string)LINQ を使用しない場合、BL では、DAL に対するメソッド呼び出しなどに制限される可能性があります。このメソッドを作成する唯一の理由は、BL のどこかで姓で顧客を取得する必要があるためです。これは、DAL コントラクトが BL のニーズによって明示的に駆動されることを意味します。一方、LINQ を使用すると、BL のニーズと DAL のコントラクトの間の具体的な依存関係から解放されます。DAL は、特定の使用法に関して完全に不可知である場合があります。エンティティとその関係のコントラクトを公開するだけであり、BL はデータの実装を気にせずに自由に使用します。それが真の関心の分離です。

LINQ の能力を従来の DAL の背後に隠しているとしたら、LINQ を使用する意味がまったくありません。

Answer 2

十分に単純なアプリケーションの場合、LINQ エンティティを直接使用することの大きな利点は単純さです。コードに別のレイヤーを含めることを回避できます。また、ビジネス オブジェクトから LINQ エンティティにマップするためのボイラープレート ロジックを大量に記述する必要もありません (ただし、AutoMapperなどのツールは非常に役立ちます)。

一方で、あなたが言うように、あなたのデータベースはおそらくあなたのドメイン モデルのイメージではありません。繰り返しになりますが、特定の物理データベース モデルと論理ドメイン モデルをマッピングするためにこの機能が必要な場合は、代わりに Entity Framework を検討する必要がありますか? これがまさに EF の主力です。これら 2 つのモデルと、それらの間のマッピング レイヤーです。

マルク

Answer 3

場合によります

ドメイン オブジェクトが非常に単純で、プロジェクトが小さい場合、それらのクラスを使用しても問題ありません。これらのクラスを繰り返すだけの余分なレイヤー全体を作成するのは時間の無駄です。

オブジェクトが複雑で、単純な方法でマッピングできない場合は、それらの詳細をデータ アクセス レイヤーから分離するために別のレイヤーが不可欠です。

本当に確信が持てない場合は、それらを直接使用して開始し、必要になることが明らかになったら別のレイヤーを追加できます。

Answer 4

シナリオによると思います。

私は現在、WCF サービスを作成しています。データ モデルはそれほど複雑ではありませんが、すべてのテーブルに外部キーがあり、テーブル間の関係により、linq は非常に複雑なオブジェクト ツリーを作成します。

クライアントの観点からは、このオブジェクト ツリーをすべて取得することは意味がありません。また、返される xml メッセージは非常に重くなります (したがって、メッセージ サイズの最大許容値を変更しないと、エラーが発生します)。

この場合、LINQ オブジェクトのカスタム ビューを作成して、クライアントが取得する予定のデータだけを返す必要がありました。ほとんどのエンティティを書き直さなければならなかったので、これは非常に苦痛ですが、最終的にはクライアントとの通信を完全に制御できます。