0

私のプロジェクト (WCF REST サービス) の 2 つのアプローチについては、一歩後退しました。

  1. 完全な OData サービス スタックをサポートするため、WCFDataServices から開始しましたが、CRUD 操作の検証要件が増えたため、EF を使用する「WCF サービス」に切り替えました。
  2. そして今、セルフトラッキングエンティティを使用してエンティティをクライアントに公開することに戻ることを考えています。多くの記事では、STE は Microsoft によってサポートされなくなり、OData を使用することをお勧めします (ただし、WCFDataService は私には適していません)。

クライアント上でエンティティを公開するための最適な設計を提案してください。または、エンティティ モデルのカスタム クラス (データ コントラクト) を作成する必要がある場合もあります。ただし、これにより (Custom と Entity 間のオブジェクトの変換のための) コードが増加し、保守性が低下します。

私のエンティティを公開するための最善の方法があるかどうかを提案してください。あなたの提案は価値があり、最も高く評価されています。

4

1 に答える 1

0

ファウラーの分散オブジェクト設計の第一法則は、「オブジェクトを配布しないでください」と述べています。これは、実際のエンティティ自体ではなく、コピーを提供することを意味します。データ コントラクト名前空間にエンティティのミラー コピーを作成すると、データベース スキーマの変更が必要になった場合でも、柔軟性が大幅に向上します。データ コントラクトが最初はエンティティと同一である場合、AutoMapper などのツールを使用すると、記述する必要のあるすべての変換コードが不要になります。構成が完了すると、エンティティをデータ コントラクトに変換するのは 1 つのライナーになります。

Mapper.Map<CustomerDto>(customer);

これにより、顧客エンティティが取得され、新しい顧客 dto が返されます。これはすべて慣例に基づいており、プロパティ名を一致させることで機能します。データ コントラクトがエンティティと完全に同一ではない場合でも、AutoMapper が把握できないプロパティについて AutoMapper にプロンプ​​トを表示するだけで済みます。

于 2013-06-26T21:13:36.173 に答える