例:クラスライブラリを作成してメインプログラムで参照する代わりに、メソッドをWebサービスとして公開します。
このように、メソッドを変更するときに再コンパイルする必要はありません。変更する必要があるものは何でも変更できますが、ネットワークのオーバーヘッドが発生します:(
それをすることを考えていますが、確かではありません。(ネットワークのオーバーヘッドが気に入らないのは不要のようです???)。
デカップリングレイヤーが良いアイデアである理由はたくさんあります。SOAはそれを達成するための最も根本的なソリューションの1つですが、消費コンポーネントのコンパイルを回避することは、デカップリングが必要かどうかを判断するための良い基準ではないでしょう。
This way you do not need to recompile when you want to change the method...
本当じゃない。メソッドを変更する必要がある場合は、Webサービスホストを再コンパイルする必要があります。
SOAを使用することは、分散ネットワークアプリケーションを使用している場合にのみ有効です。おそらく、クロスプラットフォームである必要もあります。サービスを使用してアプリケーションのルーチンタスクを実行するローカルアプリの場合は間違っています。
Webサービスを使用せずにSOAスタイルを実装できます。これは、達成しようとしている分離を模倣します。パブリックメソッドが変更されていない限り、コンシューマーを再コンパイルする必要はありません。これが当てはまらないのは、バージョン管理されたファイルを使用していて、バージョンを変更した場合のみです。
public class MyFakeService
{
public static int DoSomethingHere(int value1, int value2)
{
// Do stuff here
}
}
今あなたの消費者に....
public void MyMethod()
{
int value1 = 3;
int value2 = 4;
int newvalue = MyFakeService.DoSomethingHere(value1, value2);
Console.WriteLine(newvalue);
}
MyFakeServiceをどのように変更するかに関係なく、パブリック署名とクラス署名が同じである限り、問題はありません。
Webサービスのアイデアは、再コンパイルを停止することではありません。クライアントがわからず、クライアントとサーバー間で共通の通信パスを作成する必要がある場合は、Webサービスを使用する必要があります。たとえば、Webサービスをデプロイする場合、.Netクライアントでさえ、wsdlを調べてサービスを呼び出すことにより、コードを生成できます。
ただし、メインプログラムのみがこのメソッドにアクセスする場合は、ライブラリとして使用する方が適切です。