3

既存のビジネスロジック/データアクセス層を置き換える「中間層」を開発しています。私たちが抱えている設計上の懸念の1つは、複数の顧客のデータベースや中間層の部分が、ホストされている製品の一部として同じサーバー上に存在できるように設計する必要があるということです。ホストされた環境のデータベーススキーマとセットアップは、すでに本番環境にあるため、この時点でかなり固定されています。基本的に、ホストされた環境の特定のDBサーバーでは、各顧客は、一意の顧客IDを使用して名前が付けられたSQLServerインスタンスを持っています。

私たちが決定しようとしているのは、クライアントアプリからWebサービス、ビジネスロジック、および各顧客のデータベースへのデータアクセスを介して個別のパスを使用するか、各部分の単一の共有インスタンスを使用するかです。ここで、データアクセス層は、正しいSQL Serverインスタンス、またはこれら2つの間のどこかからデータを取得する役割を果たします。すべての共有パスが1つであるため、1つのピースがダウンすると、それにアクセスするすべてのクライアントが水中で死んでしまいます。一方、顧客ごとに個別のパスがある場合、おそらく過度に複雑になるだけでなく、（一見）維持する必要があるものがたくさんありますか？これが私たちが検討している2つのオプションの恐ろしいASCIIアート画像です：

[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]
          |--> [Web Service] --> [Business Logic] --> [Data Access] ----|
[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]

またはこれ：

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]

これらのどれ（またはその中間のオプション）が優れているのか、そしてその理由は何ですか？

4

1 に答える 1

2

これはかなり一般的な質問なので、かなり一般的な答えを出します。私は過去に同様の原則に基づいてプラットフォームを構築しましたが、私があなたに与えることができる唯一のアドバイスは、アーキテクチャを2つの層に分割することについて慎重に考えることです。

  • すべての一般的な一般的な操作を処理する完全に一般的なフレームワーク
  • カスタマイズ可能な「顧客」固有のレイヤー。このレイヤーには、通常とは異なるクライアント固有の機能を含めることができます。

多くの顧客がジェネリックフレームワークだけで操作できるのは素晴らしいことかもしれませんが、顧客がいくつかの懇願に対してあなたにお金を払っても構わないと思っているときは、ジェネリックレイヤーへの拡張ではなく変更を通じてそれらに対応できます。

一般に、この種の拡張性と、かなり標準的な手法（処理の「パイプライン」を定義する顧客ごとの構成ファイル、顧客アセンブリの動的ロード、インターフェイスの寛大な使用、汎用コンポーネントが操作を委任できるようにする）を通じて、汎用と特殊な動作の結合を処理しました標準実装または実行時の顧客固有の実装などに。

お役に立てば幸いです。

于 2011-02-16T21:57:18.183 に答える