サーバーベースの再利用-DLL、GAC、またはREST？

Question

同じサーバー上の複数の異なるアプリケーション（クライアント）によって使用される機能があります。サービスとしてモデル化するのが最適であり、バックエンドデータベースを持ち、一度に1つのバージョンの機能とデータベースのみが使用されます。

これまで、機能、構成ファイル、および使用されるすべての場所に展開された依存関係を備えた、単純なDLLの再利用を採用しました。変更はいくつかの場所で行う必要があるため、この方法は、新しいバージョンの機能を作成するとき、または新しいクライアントがそれを使用したいときに苦痛です。

これを行うためのより良い方法があるかどうか疑問に思っており、2つの可能な選択肢を考え出しました。

1. DLL（および依存関係）をGACに入れます。問題は、コンポーネントの構成方法です。クライアントは構成に関心がないため、サーバー上のハードコーディングされたパスに構成ファイルを保存することに傾注しています。

2. 機能を内部（RESTベース）サービスとして公開します。ファイアウォールを使用して、内部クライアントにアクセスを制限できます。

見てのとおり、＃1の長所はパフォーマンスであり、おそらくセキュリティであるように見えますが、＃2は設定が簡単であると考えられます。

ここで重要なものがありませんか？誰も以前に同様の状況にあり、洞察を共有したいですか？

Answer 1

これは私が何度も苦労してきた問題であり、それ以外の場合はそれ以外の最善の答えはありません。私の個人的な意見では、いくつかの理由でオプション1から離れる必要があると考えています。

1. すべてのクライアントに単一のバイナリを共有させることにより、変更を行うたびにすべてのクライアントをテストする必要があります。コンポーネントの背後にあるデータベースを変更すると想定できるため、とにかくこれを行う必要があるかもしれないことを正確に知っています。
2. ハードコーディングしないでください。 machine.configファイルのAppSettingsセクションに構成パスを保存できます。

オプション2については、WCFを使用することもできます（環境でサポートできる場合）。 WCFを使用すると、バイナリセリレーションを使用したTCPトランスポートを使用できます（共有メモリトランスポートがある場合もあります）。これらは両方とも、パフォーマンスのギャップを縮めるのに役立ちます（ただし、オプション1は常にサービスベースのアプローチよりも優れています）。

オプション2を使用すると、契約が破られていないことを検証する自動テストを開発できるため、すべてのクライアントを再テストする必要も軽減されます。これにより、単一の場所に公開し、クイック自動テストを実行し、クライアントを壊さないことを知ることができます。

とはいえ、オプション1と適切な一連の単体テストを使用して同じことを達成できますが、私の経験に基づいて、長期的にはオプション2が簡単になります。

オプション2を使用すると、CPUの処理能力がさらに必要になった場合に、将来サービスをスケールアウトできます。

個人的には、ファイアウォールの設定、認証の処理、サービスの設定などに対処する必要がないため、オプション1の方が簡単にセットアップできると思います...たとえば、サービスをホストしているサイトがクラッシュしたり、クライアントがエラーを取得したりするなどの障害の種類。

最後の提案は、プロキシ/ファサードパターンを使用して、サービスの実際の場所からクライアントを隔離することです。これにより、クライアントコードを変更せずに時間をかけて拡張できます。

Answer 2

ジョシュがすでに言ったように、残念ながら、これらの種類の質問に対する答えは、しばしば「依存する」です。

私はGACの大ファンですが、（ほぼ）完全に動作し、頻繁に更新する必要がないと確信できるコードのみを配置する必要があります。コードが「開発中」である限り、それを使用するすべてのアプリケーションと一緒に公開するだけです。

Answer 3

オプション1の使用は、特にRESTの可用性を制限するために余分な時間を費やす必要があるため、よりシンプルで簡単になると思います。 （しゃれ！）

Answer 4

ジョシュはWCFをオプションとして指摘しており、これが私がこれに取り組む方法であることは確かです。

この問題は、まさにSOAが解決すべきものです！