2

ここで少し混乱しています。

データベースからモデル化されたエンティティ フレームワークを使用して POCO クラスを作成しました。

明らかに、私はこれらのクラスをクライアントでも使用したいと思っています (そして、それらを返送して再アタッチしたい場合は、それらの簿記があればいいでしょう)。

WCF サービス参照用に生成されたクラスを調べたところ、インターネット経由で送信するのは少し冗長に見えますが、セキュリティ的に危険なものはないようです。

それでも、これを行うことについてオンラインで何も見つけることができません。私は完全にひどい道を進んでいますか？

ヘルプ？

編集：データベースからEntityFrameworkによって生成された場合、技術的にはPOCOクラスではないと思います。考えられる混乱を解消するためだけに。

4

1 に答える 1

2

これは、システムの詳細を知らずに答えるのが難しい質問ですが、最終的には、WCF サービス コントラクトで EF エンティティを公開することが正しい方法であるかどうかは、開発しているアプリケーションの範囲と要件に影響されます。

次の質問を自問してみてください。

  1. リレーショナル モデルとオブジェクト モデルを分岐する必要がある可能性はありますか? これは多くの要因によって引き起こされる可能性がありますが、最も一般的なレポート要件は、アプリケーション オブジェクト モデルに反映させたくない特定の設計を (パフォーマンスのために) データベース スキーマに適用する場合があります。DB で生成された EF エンティティをアプリケーション レイヤー全体で使用すると、このデータベース設計に縛られる可能性があります。
  2. データベース スキーマを変更すると、クライアントがサービス参照を再生成する必要があるのではないかと心配していますか? 繰り返しになりますが、アプリケーション層全体で EF エンティティを使用すると、DB スキーマに実装された変更 (クライアントにとって重要かどうかに関係なく) がサービス インターフェイスに反映され、そのインターフェイスとのクライアントの互換性が失われる可能性があります。
  3. パフォーマンスは懸念事項ですか？あなたが述べたように、生成されたクラスは冗長です。不要な手荷物をネットワーク経由で運ぶ可能性が高く、これを最適化できます。
  4. データベース スキーマと永続化メカニズムの実装の詳細をネットワーク上およびクライアントに公開することについて懸念がありますか? データベースからモデルを生成した場合、クライアントの観点からは冗長なスキーマと永続化メカニズムに関する情報を公開するプロパティが存在する可能性があります。

要約すると、EF エンティティの公開が許容されるケースは限られているかもしれませんが、通常は、EF エンティティをリポジトリで軽量の「永続性を無視する」POCO にマップするようなパターンを変更および実装するように設計します。層。EF 4.0 は、POCO を返すコンテキストをコード化する機能を提供しますが、現在のプロジェクトでは、コード生成されたコンテキストを使用し、オートマッパーを使用して EF エンティティをデータ コントラクトにマップします。リポジトリ レイヤーの外では EF エンティティを認識するものはなく、これにより、より保守しやすく堅牢な設計が可能になると思います。

于 2010-11-16T08:52:27.547 に答える