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?
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.
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.
Ich habe diesen Ansatz aufgrund der unnötigen Komplexität aufgegeben. Siehe meine Antwort unten.
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!
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.
@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.
Tags und Links asp.net-mvc repository-pattern multi-tenant access-control