非常に複雑なマルチテナントアプリアーキテクチャを開発しています。
。
多くのお客様が使用しているアプリケーションの種類は1つだけではありません。3種類のアプリケーションがあります。
APP A、APP B、APP C
。
各アプリには顧客がいます。
APPA-顧客A1-顧客A2
APPB-顧客B1-顧客B2
APPC-顧客C1-顧客C2
。
多くの情報がさまざまなアプリ間で共有されます
「顧客A1」は、 「顧客C1」が所有するデータを操作または表示する必要があります
。
Asp net mvc、EF、SQLServerを使用していると考えてください。Wichは正しい実装ですか？
1つのサイトと多くのエリア？複数のサイトを作成しますか？複数のデータベース？1つのdbだけ？フィルタリング？SQLフィルタービュー？..。
いくつかのアプリケーション例？
編集
そして...ビジネスロジックをどこに置くか？
最初に、.Net上に独自のマルチテナントエンジニアリングスタック（フレームワーク）を構築することをお勧めします。これは、テナントごとのデータ分離、水平スケーリングのサポート、に基づくビューのフィルタリングに関するマルチテナントのすべての要件を処理します。ユーザーのテナントコンテキストと役割、テナントごとのデータモデルの拡張、テナントごとのUIのカスタマイズ、役割、特権、データスコープに基づくアクセス制限の適用-テナントごとに異なる可能性があります。
ビジネスロジックは、このフレームワークの上に構築できます。このアプローチは、製品に堅牢で強力なエンジニアリング基盤を提供します。
もう1つの方法は、すぐに使用できるマルチテナントエンジニアリングスタックをすぐに購入し、Visual Studioにインストールして、開発テンプレートとして使用することです。
理想的には、単一のアプリを備えたマルチテナントサーバーでは、データが属するテナントを指定する列だけでなく、テナントごとに物理的に異なるデータベースが必要です。
ただし、どちらの方法でも、すべてのデータベース機能が正しいデータベース接続またはテナント列キーを使用していることを確認する必要があります。それが本当の問題です
これを確認する方法は、この決定を行うアプリごとに1つの関数のみを持ち、この関数を呼び出さなかった場合はすべてのデータベース関数が失敗することを確認することです（直接または以下のように間接的に）
たとえば、global.asax AuthenticateRequestまたはBeginRequest関数のMVCを使用すると、ユーザーが誰であるかを検証してから、使用する必要のあるデータベース接続またはその要求のすべてのクエリで使用する必要のあるテナント列キーを計算できます。その後、これはセッション変数などに保存されます
アプリが3つある場合は、3つの別々のサイトを作成します。共有プロジェクトを介して共通のクラスを共有できます。それらを別々に展開できれば、一般的に生活は楽になります
これは具体的な答えですが、これを設計するときに考慮できるいくつかの側面があります。
共有情報に関して、ここで最も重要なことは、お客様と、各お客様が他のお客様に対して持つ役割や権利との関係を定義することだと思います。最善のアプローチは、何ができるかを正確に特定することから始めることです。
例：
Read Only|cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 1 | 0 | 1
Write |cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 0 | 0 | 1
したがって、上記では、customer1はcustomer2のデータの読み取りと書き込み（更新）を行うことができます。
そうは言っても、主な問題はこれらの関係、つまり共有情報をモデル化することです。@TFDの提案を使用すると、顧客が関連するテナントIDとともにログオンしたときに、これらの関係をセッションにロードできます。
（提供された情報に基づくと、これはアプリケーションごとの懸念であり、顧客だけの懸念ではない可能性があります。これを説明するために、上記の表の「cust」の値をに置き換えてAppください。）
機能は共有されていますが、アプリケーションごとに固有の目的があると想定しているため、アプリケーションごとに個別のサイトを作成します。
他のデータ間の関係がある場合は、別の構成DBが必要になる可能性があります。DBは、各アプリのすべてのテナント情報（他のアプリとの関係を含む）を保存します。この提案の理由は、私が見ることができることから、共有DBアプローチを使用して互いに独立した3つの別々のマルチテナントアプリがあるためです-しかし、各アプリはあるレベルで別のアプリと対話する必要があります。
DB内の顧客に関しては、「Customers」テーブルをConfigDBに限定することをお勧めします。その後、各アプリケーションの要件に基づいてコンテンツDBを作成できます。
私の提案は、PRISMをSliverlightおよびMVVMデザインパターンで使用することです。PRISMは、各アプリケーションが独立しており、PRISMによって公開されるイベントを介して相互に通信できるような種類の複合アプリケーション向けに設計されています。
複数のアプローチが可能です。アプリはデータ駆動型であるため、アプリケーションのバグが発生した場合でもデータを保護するデータベース設計を構築することは理にかなっています。
これを行う1つの方法は、任意のテーブルにアクセスするためのストアドプロシージャがあり、セキュリティロジックがストアドプロシージャに組み込まれていることを確認することです。顧客ごとに異なるdbユーザー名が使用されていること、およびこのdbユーザー名がマッピングテーブル内のそのテナントIDに対してマップされていることを確認できます。次に、ストアドプロシージャは、要求/変更されているデータが、（コンテキスト情報を使用して）プロシージャを実行しているdbユーザーにマップされたテナントIDに実際に属していることを常に確認できます。
次に、アプリケーションによって作成されたdb接続が、そのテナントIDにマップされる対応するユーザー名のみを使用するようにするための何らかの方法が必要になります。これは、この情報（おそらく入力としてusername / idを使用）を提供するもう1つのストアドプロシージャが必要であることを意味し、このストアドプロシージャは共通のdbユーザー名を介して実行可能である必要があります。これは、この一般的なdbユーザーに実行特権を与える必要がある唯一のストアドプロシージャであることを忘れないでください。
これは大量の余分なコードを書いているように見えるかもしれませんが、アプリケーションのバグが原因であっても、データベースが不正なリクエストを拒否することを知っておくと非常に役立ちます。あなたが本当に、本当に注意している唯一の場所は、そのユーザーIDに適切なテナントデータベースのユーザー名とパスワードを取得する場所であり、それはかなり可能であるはずです。