1

私は、エンティティフレームワークコンテキストの周りにWCFデータサービスを作成し、それをEFコンテキストとしても使用できる方法を検討していました。

XMLとJSONを含むStackOverflow用のODataAPIを30分で作成

私は本当にこれを見始めたばかりですが、ビジネスロジックはどこに行くのだろうかと思っていました。サービスとしては、検証なしでは自由に追加/削除することはできないと思います。

このサービスを利用するMVCアプリを作成した場合、ビジネスロジックをどのように実装するのが最適でしょうか。属性を使用して実行できる単純なプロパティレベルの検証ではなく、最初にデータストアをチェックする必要があるより複雑なものなど。

4

4 に答える 4

2

一部をDataServiceクラスに入れることはできますが、そこでできることとできないことには制限があります。そしてもちろん、サービスの上のクライアントにいくつかを配置することもできますが、それも理想的ではありません。

私はWCFデータサービスに数週間しか費やしていませんが、あなたはそれに関する大きな問題（柔軟性の欠如）を強調しています。迅速な開発とLOBアプリケーションの強化には最適ですが、意図的な設計を備えたものを実装するのは非常に困難です。オブジェクトをサービスを通じて公開できるようにするために、エンティティモデルにオブジェクトを含める必要がありました。また、単純なプロパティを使用してこれらのクラスを拡張しようとすると、大きな頭痛の種になりました。

WCF Data Servicesは、非常に高速な開発が必要な非常に単純なアプリケーション（たとえば、1日または2日の開発サイクル）にのみ使用することをお勧めします。それ以外のことは、通常のWCFサービスで徹底的に行う価値があり、独自のデータレイヤーを作成するなどです。

于 2012-07-19T01:35:08.163 に答える
2

カスタムデータサービスプロバイダー（msdnリンク）が必要なようです。これらは非常に強力で、すべての読み取り/書き込みロジックを完全に制御できます。

たとえば、更新プロバイダーでライセンスロジックを適用するものを作成しました。

于 2012-07-19T03:08:52.103 に答える
1

特定のニーズによっては、WebAPIが適しているように思われます。Web APIは、WCF Data Servicesが持つすべてのODataサポートを取得できない場合がありますが、特定の作業（ビジネスロジックの追加など）を容易にします。Web APIによるODataの初期サポートは、かなりの数のユースケースをカバーし、時間の経過とともにサポートが拡大すると確信しています。

于 2012-07-19T15:59:18.300 に答える
0

カスタムデータプロバイダーはあなたが望むことを確実に実行し、複雑なアーキテクチャを使用している場合は優れたソリューションになる可能性がありますが、クライアントを介して保存しようとしたときに、私はそれほど興奮していませんでした。 IUpdatableインターフェイスをコンテキストの一部として実装します（コンテキストとDataServiceからリポジトリパターンを構築しようとしていました）。

多くの人にとって非常に便利だと思いますが、実際にはEntityProviderにすでに含まれている機能だけが必要であり、プロジェクトスケジュールにカスタムプロバイダーのIupdatable部分を見つける時間がなかったため、私のチーム、特にGeoff、エンティティプロバイダーに固執し、変更およびクエリインターセプターを使用して、サーバー上のビジネスロジッククラスを介してDataService要求をルーティングしました。制御の中心点を提供します。これらを使用して、セキュリティチェックを提供したり、挿入/更新で計算やその他の操作を実行したりしました。クライアントに特定のビジネスロジック機能を提供する別の方法として、サービスメソッドを使用することもできます。

于 2012-07-24T14:58:51.767 に答える