サービスをコンポーネントよりも使用するメリットとデメリットは何ですか？

Question

私は過去数ヶ月から最新のドットネットフレームワークのプロジェクトに取り組んでいます。

最新のドットネットバージョンでは、「サービス」がコンポーネントに対して推奨されています。あれは正しいですか？

私はシルバーライト（私はシルバーライトの初心者です）で見ましたが、すべてのDBレイヤー操作はサービスとして公開されています。私は現在、コンポーネントプログラムも利用できるのか分かりませんか？

利点は何ですか？すべてのレイヤーがDLLの代わりにサービスとして公開されている場合のパフォーマンスはどうですか？

私はこの概念を正しく理解し始めるべきであるということについて、この件についていくつか明言してください。

SC

Answer 1

おかげで、それは本当にサービス指向アーキテクチャに関係するすべてです - しばらくの間、一般的で、非常に人気のある何か。

アイデアは、別個の操作が互いに分離されているため、それらを使用するアプリケーションを再コンパイルせずに再利用および変更できるという考え方です。 DLL内のコードがどこでも変更されコピーされるのではなく、特定の処理または情報ソースに対して単一のアクセスポイントを表すサービスを展開することができます。

クレジットカード確認コンポーネントがあるとします。このコードを記述してDLLにコンパイルし、すべてのアプリケーションでそのコードをインクルードすることができます。バグやCC検証の変更のルールに気付かない限り、それは間違いありません。または、それをブラックリストと照合するためにアップグレードしたいかもしれません。あなたは、それを使用するアプリケーションを再コンパイルせずにこれらのことを行うことはできません。

ただし、サービスとしてクレジットカード確認が公開されている場合は、変更を加えて1か所に展開できます。署名が同じであれば（同じパラメータと応答）、アプリケーションは変更されたことを知る必要はありません。

コンポーネントに対するサービスを使用するもう1つの利点は、サービスをどこにでもホストできることです。それらは、ローカルサーバー上または世界の他の側にあることができます。

このように言えば、ケースバイケースでアーキテクチャを決定する必要があります。クレジットカードによる検証は、サービスが有用な場合の良い例ですが、HTMLコントロールをレンダリングするサービスを提供することはあまり意味がありません。

Answer 2

何か他の点を考慮する必要があります。機能が「サービス」として公開されているからといって、そのサービスがどこかでホストされているか、Webサービスとして公開されている必要があるわけではありません。

メモリに直接アクセスすることもできます。

関連する機能をサービスとして公開することは、アプリケーションのさまざまな部分の相互作用に関するものです。これらの部分をどのように展開/アクセスするかについては何も言及していません。

Answer 3

"クロスランゲージ"互換性は別の利点です。 JavaからもアクセスできるC＃.netでサービスを書くことができます。再利用はプログラミング言語の使用を超えています。

利点は何ですか？すべてのレイヤーがDLLSではなくサービスとして公開されている場合は、 のパフォーマンスはどうですか？

ここでは注意します。 「すべてのレイヤー」とはどういう意味ですか？ビジネス層やデータアクセス層などのアプリケーション層??私はこれが有用であるかもしれないとは思っていませんが（もちろんそれはあなたの文脈に依存します）、通常、サービスはさまざまな状況で再利用できるものです。例として、財務コードを検証するサービスがあります。その後、アプリケーションのビジネス層からこのサービスを呼び出します。ビジネスレイヤを別のサービスとして公開し、データアクセスレイヤを別のサービスとして公開するケースは想像もできません。通常は、開発中のアプリケーションに特化しています。たとえば、ウェブから（Webアプリケーションとして）アクセス可能なアプリケーションがあり、他のアプリケーションが使用できるWebサービス（別の種類のAPI）を介して別のエントリポイントがあります。それは意味をなさないでしょうが、ビジネス層を直接公開するのではなく、Webサービス（ビジネスロジッククラスに委任する軽量ファサード）である「ゲートウェイ」を作成します。