12

Rob Conery の MVC Storefront に基づくマルチテナント ASP.NET MVC アプリケーションでは、リポジトリまたはサービス層でテナントのデータをフィルタリングする必要がありますか?

1. リポジトリでテナントのデータをフィルタリングします。

public interface IJobRepository
{
    IQueryable<Job> GetJobs(short tenantId);
}

2. サービスがリポジトリ データをテナント別にフィルター処理できるようにします。

public interface IJobService
{
    IList<Job> GetJobs(short tenantId);
}

私の直感では、サービス層でそれを行うように言っていますが (オプション 2)、各テナントは本質的に独自の「仮想リポジトリ」を持つべきであり (オプション 1)、この責任はリポジトリにあります。

  • 最もエレガントなアプローチはどれですか: オプション 1、オプション 2、またはより良い方法はありますか?

アップデート：

リポジトリでフィルタリングするという提案されたアイデアを試しましたが、問題は、アプリケーションが (サブドメインを介して) テナント コンテキストを提供し、サービス レイヤーとのみ対話することです。リポジトリ層までコンテキストを渡すのが使命です。

代わりに、サービス層でデータをフィルタリングすることにしました。リポジトリは、サービス レイヤーで使用されるテナント固有のデータを取得するための適切なフィルターを使用して、リポジトリで物理的に利用可能なすべてのデータを表す必要があると思います。

最終更新:

不必要な複雑さのため、私はこのアプローチを断念しました。以下の私の答えを見てください。

4

2 に答える 2

5

@FreshCode、リポジトリでそれを行い、パラメータとしてテナントを渡しません。次のアプローチを使用します。

public IQueryable<Job> GetJobs()
{
    return _db.Jobs.Where(j=>j.TenantId == Context.TenantId);
}

コンテキストはリポジトリが持つ依存関係であり、たとえばURLに基​​づいてテナントを決定するBeginRequestで作成されます。このように、それはかなり透明でありtenantId、少し邪魔になるかもしれないパラメータを避けることができると思います。

よろしく。

于 2010-04-30T15:08:17.807 に答える
3

更新:マルチテナント アプローチを採用しないことで、何百時間もの技術的負債が発生しました。4 年後、最初に時間をかけてクリーン テナント アプローチを実装したかったと思います。同じ間違いをしないでください！

古い、時代遅れの答え：

テナントごとに個別のアプリケーションとデータベースを使用することを優先して、すべてのマルチテナント コードを削除することになりました。私の場合、頻繁に変更されないテナントがほとんどないため、これを行うことができます。

コントローラー、メンバーシップ プロバイダー、ロール プロバイダー、サービス、およびリポジトリのすべてがあちこちでコードの重複に引き寄せられていたため、 99% の確率で 1 つのテナントに固有のデータにアクセスするのに.WithTenantID(...)1 つのテーブルは必要ないことに気付きました。 Users、したがって、別々のアプリケーションを使用することは、より理にかなっていて、すべてが非常に簡単になります.

回答ありがとうございます。再設計が必要であることに気付きました。

于 2010-05-08T13:15:38.367 に答える