1

エンティティ フレームワークで STE を使用する場合、wcf 経由でエンティティを受け取るクライアント アプリケーション (Web サイトなど) を構築する場合、すべての機能を実現するためにモデル dll アセンブリ (クラスの定義を含む) を参照する必要がありますか? STEの？

または、サービス wsdls から生成されたプロキシ クラスを使用するだけで、どの機能が失われますか?

4

2 に答える 2

2

100% とは言えませんが、STE は逆シリアル化後に追跡を開始するように設計されています。生成されたプロキシ クラスを使用することになると、クライアント側の追跡コードがすべて失われます。生成されたエンティティが、エンティティがクライアント プロキシからサーバー側で復元されるときに発生する変更を追跡できるとは思わないので、モデル アセンブリを参照することは間違いありません。

于 2011-01-07T13:59:56.540 に答える
0

STE は、シリアル化解除後に追跡を開始するように設計されています。一般に、自己追跡機能は、ワイヤの必要な変更のみを渡すように、何が変更されたかを判断するのに役立ちます。

Self Tracking Entitiesは、Entity Framework v4 で導入された EF のファッショナブルな実装です。追跡コンテキストがエンティティ自体から分離されている EF6 では、DbContext (サーバー) と ODataClient (クライアント) に取って代わられました。

STE モデルは通常、生成されたプロキシ クラスの代わりにクライアント側で dll が使用されることが期待される RPC スタイルの結合用に設計されたモデル クラス内に豊富なビジネス ロジックのセットを組み合わせます。

クライアントで WSDL または $metadata から生成されたプロキシクラスを使用する場合、モデル内のカスタム ビジネス ロジックはクライアントに存在しません。このビジネス ロジックは、変更を検証、拒否、または反応するプロパティ セッターまたは変更ハンドラー内のコードの形式になります。この複雑なロジックをクライアントに実装する唯一の方法は、dll をクライアント側の開発者に配布することです。それ以外の場合は、必要に応じて複製できる彼らの能力に頼る必要があります。

STE は、クライアントで実行されるサーバー定義のビジネス ロジックを発行するメカニズムを提供するリモート コードソリューションを提供し、ビジネス ルールを検証し、ネットワーク経由で送信されるバイト数を削減するという明確な意図を持っていました。

クライアントで単純な CRUD 変更追跡を生成することはできますが、生成されたプロキシ クラスを使用することになる場合、サーバー定義は完全に無視され、サーバーで定義されている可能性のある豊富な追跡および検証コードが失われます。

クライアント側で生成されたプロキシが使用される場合、サーバーから作成できる仮定はありません。API プロジェクトでは、クライアントが dll を使用せずに独自のプロキシを生成することを常に選択できるため、クライアントからのすべての入力を再検証、サニタイズ、検証することが重要です。

変更履歴をネットワーク経由で送信することは実際的ではありません。ほとんどの STE 実装では追跡を使用して送信する情報を決定しますが、サーバーは変更スタックを受信せず、代わりにサーバー ロジックがペイロード全体を想定することが予想されます。 (エンティティをサーバー コンテキストにアタッチすることによって) 格納する必要がある完全な状態を表すか、サーバーに格納されている現在の値と比較して独自の変更グラフを生成する必要があります。

STE の作成者は、必要に応じてクライアント モデルを利用できるようにします。一般に、DLL が提供されている場合、DLL を使用すると多くの時間と管理を節約できます。

STE は時代遅れになりました。これは主に、準拠した DLL を提供する API 開発者のメンテナンス負担によるものですが、一般に API のサブセットのみを必要とし、ソリューションを受け入れる可能性が高いクライアントによる採用率の低さによるものです。これは、サーバーの物理的な実装と構造から分離されています。EF と OData は、STE Framwork が対処するように設計された元の問題に対処するために進化しました。

于 2021-07-15T11:05:57.827 に答える