Multi-Tenant-Zugriffskontrolle: Repository oder Service-Schicht?

Question

In einer Multi-Tenant-Anwendung ASP.NET MVC basierend auf Rob Conery MVC Storefront, soll ich den Mieter Filtern von Daten werde in der Repository oder Service Schicht

1. Filter Mieter Daten im Repository:

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

2. Lassen Sie den Service-Filter die Repository-Daten durch den Mieter:

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

Mein Bauchgefühl sagt, dass es in der Dienstschicht tun (Option 2), aber es könnte argumentiert werden, dass jeder Mieter im Wesentlichen sollte ihren eigenen „Virtual Repository,“ hat (Option 1) wo diese Verantwortung liegt mit dem Repository.

• Welches ist die eleganteste Ansatz ist: Option 1, Option 2 oder gibt es eine bessere Art und Weise

---

Update:

habe ich versucht, die vorgeschlagene Idee der Filterung im Repository, aber das Problem ist, dass meine Anwendung den Mieter Kontext (über Sub-Domain) und nur interagiert mit der Dienstschicht zur Verfügung stellt. Vorbei an dem Kontext der ganzen Weg in die Repository-Schicht ist eine Mission.

Also anstatt habe ich entschieden, meine Daten in dem Service-Layer zu filtern . Ich glaube, dass das Repository alle Daten physisch in dem Repository mit geeigneten Filtern für die Beschaffung von mandantenspezifischen Daten darstellen soll, durch die Dienstschicht verwendet werden.

Endgültigen Update:

I beenden diesen Ansatz bis zu verlassen aufgrund der unnötigen Komplexität. Siehe meine Antwort unten.

Answer 1

Update: nicht mit einem Multi-Tenant-Ansatz Kosten mich Hunderte von Stunden in technischen verschulden. Vier Jahre nach der Zeile, ich wünschte, ich die Zeit nahm zunächst einen sauberen Mieter Ansatz zu implementieren. Sie nicht den gleichen Fehler machen!

---

Alt, veraltete Antwort:

endete ich die gesamten Code Multi-Tenant-Strippen bis zu Gunsten der Verwendung von separaten Anwendungen und Datenbanken für jeden Mieter. In meinem Fall habe ich einige Mieter, die nicht oft ändern, so kann ich dies tun.

Alle meine Controller, Mitgliedschaftsanbieter, Rollenanbieter, Dienstleistungen und Repositories wurden gravitierende zu doppelten .WithTenantID(...) Code ganz über dem Platz, das machte mir klar, dass ich nicht wirklich eine Users Tabelle den Zugriff auf Daten benötigen haben, die spezifisch für einen Mieter 99% der Zeit, so mit separaten Anwendungen macht einfach mehr Sinn und macht alles so viel einfacher.

Vielen Dank für Ihre Antworten - sie machte mir klar, dass ich ein Redesign erforderlich

.

Answer 2

@FreshCode, wir tun es im Repository, und wir nicht den Mieter als Parameter übergeben. Wir verwenden den folgenden Ansatz:

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

Der Kontext ist eine Abhängigkeit der Repository hat, und das ist in der Beginrequest erstellt, wo Sie die Mieter bestimmen basierend auf der URL zum Beispiel. Ich denke, auf diese Weise ist es ziemlich transparent und Sie können den tenantId Parameter vermeiden, die ein wenig zu stören werden kann.

Viele Grüße.