.NET-Mitgliedschaft mit Repository-Muster

Question

Mein Team ist im Begriff, ein Domänenmodell zu entwerfen, die verschiedenen Datenquellen hinter einer einheitlichen Repository Abstraktion verstecken. Einer der Hauptgründe für diesen Ansatz ist die sehr hohe Wahrscheinlichkeit, dass diese Datenquellen signifikante Veränderung in naher Zukunft durchlaufen werden, und wir wollen nicht, neu zu schreiben Business-Logik werden, wenn dies geschieht. Eine Datenquelle wird unsere Mitgliederdatenbank sein, die ursprünglich mit dem Standard ASP.Net Mitgliedschaftsanbieter implementiert. Der Mitgliedschaftsanbieter ist mit dem System.Web.Security Namespace gebunden, aber wir haben eine Design-Richtlinie verlangt, dass unsere Domain-Modell Schicht auf System.Web nicht abhängig ist (oder jede andere Implementierung / Umwelt Abhängigkeit), wie es in verschiedenen Umgebungen verbraucht wird - noch wir wollen, dass unsere Websites direkt mit Datenbanken in Verbindung stehen.

Ich erwäge, was ein guter Ansatz wäre, den MembershipProvider Ansatz mit unseren abstrahierten n-Tier-Architektur in Einklang zu bringen. Mein erster Eindruck ist, dass wir einen „DomainMembershipProvider“ schaffen könnten, die mit dem Domänenmodell in Wechselwirkung tritt und dann Objekte im Modell umzusetzen, die mit dem Repository umgehen und Validierung / Geschäftslogik behandeln. Das Repository würde dann Daten implementieren Zugriff über unser (bis jetzt noch unentschieden) ORM / Datenzugriffstool.

Gibt es irgendwelche eklatante Löcher in diesem Ansatz - ich habe nicht eng mit der MembershipProvider Klasse funktionierte so gut, etwas fehlen. Alternativ gibt es einen Ansatz, den Sie denken, wird besser auf die Anforderungen dienen ich oben beschrieben?

Vielen Dank im Voraus für Ihre Gedanken und Ratschläge.

Viele Grüße, Zac

Answer 1

Es ist 6 Monate her, seit die Frage gestellt wurde, und niemand scheint eine Antwort geben konnten, so glaubte ich, die Lösung erklären würden wir schließlich entschieden haben.

Im Grunde haben wir beschlossen, keine Umsetzung des MembershipProvider zu verwenden - stattdessen verwenden wir unsere eigene Mitgliedschaft Dienst auf einem Repository sitzen. Es war wichtig, dass wir die bestehende aspnet_Membership Datenbank so unser Repository zu halten hat sich die im Grunde dupliziert eingebaute in SqlMembershipProvider Funktionalität (zumindest die Aspekte, die wir brauchen davon) - zunächst über Linq-to-SQL, aber jetzt sind wir zu NHibernate Übergang . Der Plan ist es, die Mitgliederdatenbank in einem Jahr zu ersetzen oder so, wenn alle unserer Websites aktualisiert werden, das neue Modell zu verwenden.

Es war möglich, einen benutzerdefinierten Mitgliedschaftsanbieter zu verwenden, aber am Ende wurde es offensichtlich, dass es einfacher war, konsistentere und besser verwaltbar eine benutzerdefinierte Implementierung zu verwenden. Wir sind immer noch mit der integrierten in Formularauthentifizierung Funktionalität zur Überprüfung, ob ein Benutzer in und zum Umleiten Benutzer, die versuchen werden protokolliert, sichere Bereiche unserer Website zuzugreifen, ohne zunächst authentifiziert werden - aber wir haben die Funktionalität außer Kraft gesetzt, die die Profil-Provider gebunden ist .

Letztlich unsere Gefühle zu diesem Thema sind, dass während der Mitgliedschaftsanbieter ein leistungsfähiges und einfach zu bedienendes Werkzeug in ASP.Net ist, wenn es nicht mit dem breiteren Ansatz in Ihrer Anwendung verwendet paßt, ist es eine Überlegung wert, eine alternativer Ansatz.

Answer 2

Interessant, vielen Dank für Ihre endgültige Lösung veröffentlichen. Ich bin in einer ähnlichen Situation, aber das Schreiben eines benutzerdefinierten MembershipProvider. Ich weiß nicht, wo der Anbieter setzen, weil sie Zugriff auf die DB sowie System.Web-Namespace muss. Es scheint, wie es die eine Klasse ist, dass diese ganze Trennung von Bereichen Design verletzt.