2

私は過去 5 か月間アプリケーションを開発してきましたが、この問題に遭遇しました。

私たちは EF5 を使用しており、この質問と同様に、すべてのエンティティ クラスが抽象基本クラスから派生するようにクラス階層を設計し、検証インターフェイスの実装を強制しました。また、エンティティ クラスで検証属性を使用しています。

WCF サービスでエンティティ クラスの使用を開始するまで、すべてが正常に機能していました。一連のシリアライゼーション例外が発生しており、設計で破った「POCO」ルールを見つけようとしています。 この記事では、クラス (明らかに...) を抽象化することはできませんが、私のクラスは抽象クラスから派生しているため、知らないルールを破ったのでしょうか?

更新:ここに私が苦労している例外があります:

System.Runtime.Serialization.SerializationException、mscorlib、バージョン = 4.0.0.0、カルチャ = ニュートラル、PublicKeyToken = b77a5c561934e089

Type 'System.Data.Entity.DynamicProxies.WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD' with data contract name 'WorkSession_63308485A9007DE087FF55AD9F246FD677863AA39AD56FEF4586AB87E21832DD: http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies ' is not expected. DataContractResolver の使用を検討するか、既知の型のリストに静的に認識されていない型を追加します。たとえば、KnownTypeAttribute 属性を使用するか、DataContractSerializer に渡される既知の型のリストにそれらを追加します。

4

2 に答える 2

2

POCO は遅延読み込みを使用するため、EF から実際の型を取得するのではなく、プロキシを取得して、ナビゲーション プロパティが遅延読み込み用に自動実装されるようにします。

私のアドバイスは、Web サービスからドメイン オブジェクトを公開するという考えを忘れることです。たくさんの追加の呪文が唱えられたこの特定のケースでこれが可能であることをあなたに納得させようとする答えがあるに違いありません. ただし、最も安全な方法は、思考をDTO、データ転送オブジェクト、つまり軽量で安全にシリアル化してネットワーク経由で送信できる「データのみ」のクラスの追加レイヤーを作成するパターンに切り替えることです。

DTO パターンを使用してデータを公開する方法と、AutoMapper などの追加のサポート テクノロジを説明する優れた記事が多数あります。詳細を簡単に見つけることができ、さらに回答を得るために戻ってくることができます。

于 2013-09-27T20:01:15.997 に答える
1

「POCO ルール」に違反していません。例外で言及されている「動的プロキシ」は、エンティティから派生WorkSessionしたクラスですが、コードでは派生せず、実行時に動的に派生します。Entity Framework は、既定でこれを行い、ナビゲーション プロパティ (および場合によってはスカラー プロパティ) をvirtual.

WCF を使用してエンティティをシリアル化する場合は、動的プロキシの作成を無効にする必要があります。データベースからエンティティをロードする前に、コンテキストにフラグを設定するだけでこれを行うことができます。

context.Configuration.ProxyCreationEnabled = false;

var worksessions = context.WorkSessions.....ToList();

ロードされたものは動的プロキシ型ではなくworksessions、実際のランタイム型になり、WCF はもう文句を言うべきではありません。WorkSession

于 2013-09-27T20:02:02.403 に答える