0

WCFの使用、サービスの作成、クライアントサポートについて話し合っています。

現在、サービスライブラリクライアント側のSilverlightバージョンを提供することで、Silverlightクライアントをサポートしています。これにより、インターフェイスを使用して定義されたサービスコントラクトの強い型付けを維持できます。

これは問題ありませんが、WSDLには多くのメソッドがArrayOfAnyTypeを返し、すべてがクライアント側のオブジェクトであるため(正しいタイプにキャストできますが、私が言ったように)、インターフェイスでサービスを定義すると、他のクライアントにとって厄介になります。 、その厄介な)。

メッセージ転送に明示的なDTOを使用するようにサービスを書き直し、同様のクライアント側ライブラリを使用してビジネスオブジェクトを再作成することで、サービスの相互運用性を大幅に高めることができます。

ただし、これを行うと、EntityFrameworkとそれが提供する自己追跡エンティティを使用するなど、いくつかのオプションがブロックされるように見えます。これらは、クライアントとサーバーで同じライブラリを共有する必要があり、相互運用性がないためです(これがある場合は修正してください)間違い)

相互運用性と、箱から出してすぐに使用できるより多くの機能にアクセスできることの間にはトレードオフがあるようで、ソリューションのより迅速な開発が可能になります。

だから私の質問は、相互運用性がなく、.netとSilverlightクライアントのみをサポートすることを決定することによってどのような利点が得られるかです(Silverlightクライアントをサポートすることが相互運用性がないと見なすことができる場合)?また、相互運用可能であると判断することで、どのような便利な.net機能をブロックできますか?

両方のタイプのソリューションを共存させるための標準的な手法はありますか?それにより、利用可能なすべての機能を使用して.netクライアントをサポートしながら、他の.net以外のクライアントを適切にサポートできますか?

4

1 に答える 1

0

これには Facade パターンを使用できます。

現在のロジックをビジネス レイヤーに移動し、WCF 経由で公開しないでください。

次に、サポートするコントラクトごとに 1 つずつ、2 つの WCF サービスを作成します。このレイヤーは、ビジネス レイヤー オブジェクトをコントラクト オブジェクトにマップし、ビジネス レイヤーの機能を呼び出します。

これにより、各クライアントのすべてのロジックとカスタム サービスを一元的に管理できます。

于 2011-04-21T08:39:52.013 に答える