0

近い将来、別のユーザーグループによって利用される既存のMVCアプリがあります。既存のユーザーグループと新しいユーザーグループ/プログラムの両方に、独立したデータがあります。2つのユーザーグループ/プログラムを区別するためにテーブルにフラグを追加し、アプリケーションにアクセスしてそれぞれのデータをプルアップするときにルーティングを実行することを考えていました。

ここで、コードのカスタマイズに関しては、たとえば、あるグループ/プログラムが、最初のグループが望まないページに追加のフィールドを持ちたい場合、またはアプリケーションのプロセスフローが2つのユーザーグループ間で分離されている場合です。

上記の2つのシナリオが頻繁に発生する場合は、プログラム/ユーザーグループごとにコードをカスタマイズするのではなく、新しいWebインスタンスとデータベースインスタンスを実行する必要があります。このようにして、私の顧客/ユーザーグループの両方が、アプリケーションに異なるロジック/フィールドを追加する柔軟性を持ちます。

非マルチテナントアプローチで私が目にする唯一の欠点は、2つの別々のアプリケーションを維持するための開発者による時間の労力です。異なるユーザーグループ/プログラムごとに同じコードベースをカスタマイズするために、コンティショナルロジックを追加するのが怖いです。インフラストラクチャのコストは問題ではありません。また、このアプリケーションが2つ以上のユーザーグループ/プログラムによっていつでも使用されることはないと思います。それで、皆さんは私がどのアプローチを取るべきか、そしてその理由をどう思いますか？よろしくお願いします

PSユーザーは、他のテナントのデータを見るためにサイトをハッキングしようとする忍者を借りません。彼らは企業ユーザーです。彼らはむしろこのアプリケーションを使用せず、プロセスの一部であるため、使用する必要があります。

4

2 に答える 2

3

マルチテナンシーに関するマイクロソフトの記事は一見の価値があります。

また、各クライアントが個別のフィールドとカスタマイズされた画面を持つことができるようなアーキテクチャを備えた mvc アプリの設計にも取り組んでいます。

私がたどり着いた結論は、マルチテナンシーをサポートする IOC コンテナーを使用すると、おそらく全体がずっと簡単になるということです。

Autofac には、マルチテナンシー サポートが組み込まれています。

各ビューにクライアント用のロジックを持つという点では、IOC パスをたどると、各テナント用のコントローラーを持つことができ、その場合、そのようなクライアント固有のロジックをハードコーディングすることは、必ずしもそれを持っているほど悪くはないと思います。すべてを共有コントローラーにハードコーディングします。本質的には、特定のテナント向けのコンポーネントを作成するときは、そのテナントだけがシステムを使用しているかのように書くという考え方に切り替えることができると信じています。

ビューをカスタマイズするために私がたどり着いたもう1つの解決策は、コンパイルされたビューにRazorGeneratorアプローチのバリエーションを使用することです。ここでは、各テナントのビューを個別のアセンブリにコンパイルし、スワップアウトできる独自のビューエンジン(これに基づいて)を作成しましたルーティング パラメーターの値に応じてビューを探すアセンブリ。

もちろん、私はまだこのアプローチを模索しており、どこが不十分なのかを見つけるために完全に洗い流していません。

于 2013-02-15T06:22:04.843 に答える
2

2 人のユーザーの要件の違いが画面/機能の 10% 以上である場合は、2 つのデータベースとアプリを使用することをお勧めします。10% 未満であると予想される場合は、機能が異なる場合に別のアクションを記述します (アクション名の接頭辞または接尾辞が異なる可能性があります)。

于 2013-02-15T05:59:17.237 に答える