Mandantenfähige Zugriffssteuerung: Repository- oder Service-Layer?

9

Sollte ich in einer mandantenfähigen ASP.NET MVC-Anwendung, die auf der MVC Storefront von Rob Conery basiert, die Daten des Mandanten im Repository oder der Service Ebene filtern?

1. Die Daten des Mieters im Repository filtern:

%Vor%

2. Lassen Sie den Service die Repository-Daten nach Mandanten filtern:

%Vor%

Mein Bauchgefühl sagt, es in der Serviceebene zu tun (Option 2), aber es könnte argumentiert werden, dass jeder Mieter sein eigenes "virtuelles Repository" haben sollte (Option 1) wo liegt diese Verantwortung beim Repository.

  • Was ist der eleganteste Ansatz: Option 1, Option 2 oder gibt es einen besseren Weg?

Aktualisierung:

Ich habe die vorgeschlagene Idee der Filterung im Repository versucht, aber das Problem ist, dass meine Anwendung den Mandantenkontext (über Subdomain) bereitstellt und nur mit der Serviceebene interagiert. Das Übergeben des Kontexts an den Repository-Layer ist eine Mission.

Stattdessen habe ich mich dafür entschieden, meine Daten auf der Serviceschicht zu filtern. Ich denke, dass das Repository alle physisch im Repository verfügbaren Daten mit geeigneten Filtern zum Abrufen mandantenspezifischer Daten darstellen sollte, die von der Service-Schicht verwendet werden können.

Letzte Aktualisierung:

Ich habe diesen Ansatz aufgrund der unnötigen Komplexität aufgegeben. Siehe meine Antwort unten.

    
Petrus Theron 30.04.2010, 14:52
quelle

2 Antworten

1

Update: Nicht mit einem Multi-Tenant-Ansatz zu gehen kostet mich Hunderte von Stunden in technischen Schulden. In den nächsten vier Jahren wünschte ich mir, dass ich mir zuerst die Zeit nehme, einen sauberen Mieteransatz zu implementieren. Mach nicht den gleichen Fehler!

Alte, veraltete Antwort:

Am Ende habe ich den gesamten Code für mehrere Mandanten entfernt, um separate Anwendungen und Datenbanken für jeden Mandanten zu verwenden. In meinem Fall habe ich wenige Mieter, die sich nicht oft ändern, also kann ich das tun.

Alle meine Controller, Mitgliedschaftsanbieter, Rollenanbieter, Dienste und Repositories haben sich überall auf den doppelten .WithTenantID(...) -Code konzentriert, was mir klar gemacht hat, dass ich wirklich keine Users -Tabelle brauchte, um auf Daten zuzugreifen in 99% der Fälle für einen Mandanten spezifisch, so macht die Verwendung separater Anwendungen mehr Sinn und macht alles so viel einfacher.

Danke für deine Antworten - sie haben mir gezeigt, dass ich ein Redesign benötige.

    
Petrus Theron 08.05.2010, 13:15
quelle
5

@FreshCode, wir machen das im Repository und übergeben den Mandanten nicht als Parameter. Wir verwenden den folgenden Ansatz:

%Vor%

Der Kontext ist eine Abhängigkeit, die das Repository besitzt und die in der BeginRequest-Instanz erstellt wird, in der Sie den Mandanten beispielsweise anhand der URL ermitteln. Ich denke auf diese Weise ist es ziemlich transparent und Sie können den Parameter tenantId vermeiden, der ein wenig störend werden könnte.

Grüße.

    
uvita 30.04.2010 15:08
quelle