私は、インターネットを介して第三者にデータを要求および受信するウェブサイト用のウェブサービスを実装しています。また、内部Windowsアプリケーション用のWebサービスの機能を複製するDLLを作成するように求められました。WebサービスとDLL。長所と短所?
私の質問は、 DLLを作成せず、内部アプリケーションとWebアプリケーションの両方にWEBサービスを使用する利点と欠点は何ですか?
メンテナンスの観点からは、私は単一のサービスをサポートしたいと考えています。思考やアイデア?
私は、インターネットを介して第三者にデータを要求および受信するウェブサイト用のウェブサービスを実装しています。また、内部Windowsアプリケーション用のWebサービスの機能を複製するDLLを作成するように求められました。WebサービスとDLL。長所と短所?
私の質問は、 DLLを作成せず、内部アプリケーションとWebアプリケーションの両方にWEBサービスを使用する利点と欠点は何ですか?
メンテナンスの観点からは、私は単一のサービスをサポートしたいと考えています。思考やアイデア?
WCFサービスを作成します。 Windowsアプリケーションはdllのサービスクラスに直接アクセスできますが、WCFはそれをWebサービスとして公開します。そのようにしてコードを1つ書き、維持するだけです。
私の意見では、さまざまな形式でホストできるWCF-Serviceのようなものとしてこのロジックを作成する必要があります。インタフェースを優先する開発戦略では、直接インスタンス化することでインメモリクラス以上のサービスを使用できるようになりますが、プロキシを使用して "共有メモリ"エンドポイントを使用して、 Web境界と共有メモリ、TCP/IP。
ホスティングモデルは
+ .. IISなると非常に伝統的なWebサービスのように見えるし、行動する結合basicHttpを使用するだけでなく、Windowsサービス内でホスト、またはWindowsアプリケーション、あるいはConsoleHostアプリケーションフォームすることができができ1。また、ClientBase <>を使用してServiceInterfacesを共有することで、リモートと内部のクライアントアプリケーションが同じインターフェイスを再利用できるようになり、DLLと真のWebサービスコールの間でクライアントをシームレスに切り替えることができます。 – StuartLC
これは、潜在的に多くの不必要なオーバーヘッドを追加します。 WCFサービスによって使用される共有DLLを持つことは、IMHOであり、より高速で優れたソリューションです。 – Graymatter
かなり標準的なアプローチは、サービスの実装を定義するインタフェースと、それと対話して再配布可能なアセンブリとして利用できるようにするために使用されるプロキシを使用することです。明らかに、サービス内の機能をより小さなコンポーネントやアセンブリに抽象化することも良い考えですが、サービス経由でその機能に標準インタフェース/ APIを提供することは、オーバーヘッドではなく、大きな利点です。 – fdfrye