0

専用の Web サーバーで多数の Web サイトと Web ベースのアプリケーションを実行しています。現在、同じボックスでデータベースも実行されています (これが変更される可能性はほとんどありません)。

さまざまなプロジェクトで取得している要件が互いに重複していることが多いことに気付きました。そのため、私は黙っている間に、さまざまなサイトのアーキテクチャを再計画しようとしています。

理想的には、重複する機能 (ログイン、ユーザー レポートの一部、エラー レポートなど) をコア ライブラリに抽出したいと考えました。

コア アセンブリを作成し、それを各 Web サイトのビンに追加すると、アプリ構成ファイルにあるデータベースと通信します。しかし、状況が変わると、バージョン管理/メンテナンスの頭痛の種になります。

このコア ライブラリを GAC に配置できます。つまり、登録/登録解除する必要がありますが、必要に応じてすべてのアプリで使用できます。

または、これを行う 3 番目の方法は、WCF Web サービスを使用して、AP に別の内部層を追加し、コア作業を別の Web サービスのセットに引き渡すことです。これの利点は、拡張した場合、すべてのインターフェイスを一連の Web サービスとして維持できるため、アプリは http または tcp 呼び出しを行うだけで済み、bin ファイルや gac されたアセンブリの移動について心配する必要はありません。

基本的に、私は誰かがどちらかのアプローチについて考え/コメント/批判を持っているかどうかを確認するためにここにいます主要な仕事が入ってきたように:)

4

1 に答える 1

0

必要に応じてライブラリを参照として使用することをお勧めします(アプリケーションのビンに常駐します)。

レポートの 1 つにわずかな変更が必要な場合はどうしますか? 変更を行った後、既存のすべてのアプリで回帰テストを行う予定はありますか?
dll の別のコピーを保持しておくと、必要に応じてアップグレードできます。
どのアプリがどのバージョンの dll を実行しているかを確認してください。

保守の観点からは、機能するものを常に変更したいとは限りません。
「何がうまくいかないか、うまくいかない」ので、うまくいかない可能性のある領域を制限します。

于 2012-09-07T11:20:28.573 に答える