0

私たちがやりたいのは、サービス上で典型的なPOCOオブジェクトを使用することです。サービスは実際に機能をアラカルトで提供するように作られていることはわかっていますが、実際にここで対処しようとしている問題は、クラスライブラリ(属性、コンストラクター、動作などのPOCO機能)で得られるのと同じユーザビリティを実現することです。コンパイルされたライブラリで)、「オンザフライ」と呼ばれる一元化された再利用可能なアセンブリを持つという利点があります。そうすることで、ライブラリを構築し、それを1つの場所に再デプロイすると、それを参照するすべてのアプリが更新されます。

WCFはこれを実際にはサポートしていないようですが、その理由は理解できます。ほとんどの場合、人々は見下すように嘲笑し、「なぜあなたはそれをするのですか?」と尋ねる傾向があります。さて、私はここでそれに答えました。では、私が本当に求めているのは、この種の「中央クラスライブラリ」を実現するためにどこを調べるべきかということです。サービスが答えだとは思いませんが、サービスのようにアクセスできる中央クラスのライブラリを実現する必要があります。このように、そのクラスライブラリの更新は、それを参照するすべてのアプリケーションに透過的に影響を与えるのに対し、すべてのアプリでそれを再参照する必要があります。これは意味がありますか?TIA

更新:それについて考えただけです。アセンブリをアプリケーションサーバーのGACに追加するだけではばかげているでしょうか。

4

1 に答える 1

0

私がやったことは、Webサービスをラップするクラスライブラリを作成することです。すべてのデータアクセスがサービスを介して行われている間、すべてのビジネスロジックはクラスライブラリに残ります。これにより、複雑なpingがクライアント側のプログラミングから隠され、非常に簡単でクリーンなページが作成されます。

ちなみに、WCFサービスで作成されたオブジェクトは引き続き抽象化をサポートしているため、それを少し活用することができました。クラスライブラリオブジェクトが一致するサービスデータトランスポートオブジェクトの命名規則を作成しました。ライブラリオブジェクトには、サービスオブジェクトと同じプロパティ名に加えて、実行する必要のあるその他の名前があります(リージョンで区切っています)。

ですから、これはサービスのより適切な使用法であり、私の問題をほぼ解決すると思います。かなりの余分な作業がありますが、今では、緩く結合され、非常にまとまりのある、より柔軟なアーキテクチャがあります。

于 2012-06-06T22:16:42.240 に答える