ASP.NET MVC - Wohin geht die Authentifizierungsschicht?

Ich habe eine MVC-Lösung wie folgt eingerichtet, mit drei 'Projekten'.ASP.NET MVC - Wohin geht die Authentifizierungsschicht?

Web (MVC-Projekt, Views, Controllern, Viewmodels)

Modelle (Domain Objects)

Persistenz (nHibernate Mapping, Session)

Ich brauche die Repositories zu beginnen Bau und würde mit dem Authentifizierungsmodell beginnen. Grundsätzlich nach der Standard-MVC-Vorlage, eine IMembershipService und eine IFormsAuthenticationService und verwandte Klassen (mit benutzerdefinierten Code, nicht in Authentifizierungsanbieter eingebaut).

Meine Frage ist ... wohin soll das gehen? Meine Repositories benötigen Zugriff auf meine Domain-Objekte und meine Persistenzschicht. Aber ich lese immer wieder, dass jede Art von "Kopplung" bedeutet, dass es ein schlechtes Design ist. Ich zögere also, ein viertes Projekt für die Repositories/Services zu erstellen, das auf die Models/Persistence verweist ... aber ich kann wirklich keinen anderen Weg finden, es logisch zu machen.

Quelle

2010-12-03 Ciel

Dies ist sehr subjektiv.

Machen Sie, was für Sie und Ihr Team Sinn macht.

Ich werfe sie in den Rest meiner Repositories. Ich meine, ein Benutzer ist ziemlich zentral für jedes Anwendungsrecht? Besitzt ein Benutzer etwas? Wenn ja, ist er nicht eine Wurzel?

Quelle

2010-12-03 20:48:38 jfar

Ich habe Angst, alles zu tun, was mich erfordert, einen anderen Teil der Lösung zu referenzieren. Es scheint überall, wo ich mich hinwende, alles was ich sehe sind Leute, die darüber reden, wie schrecklich es ist, irgendeine Verbindung zu irgendeinem Teil des Projekts zu haben. Nichts macht für mich und mein Team an diesem Punkt wirklich Sinn - weil es unmöglich erscheint, tatsächlich mit der Datenbank zu kommunizieren, ohne auf irgendeiner Ebene mit dem Domänen- und Mapping-Modell zu koppeln. Erlaube ich dem Repository-Bereich der Anwendung, die SessionFactory zu sehen? Muss ich alles davon abhalten, etwas anderes zu sehen? – Ciel

Ich würde mich nicht allzu sehr mit Baugruppenreferenzen beschäftigen. Tatsache ist, dass sie * miteinander gekoppelt sind. Man braucht das andere, um zu funktionieren. Es wird immer etwas Disziplin erforderlich sein, um zu vermeiden, dass etwas verwendet wird, was technisch verfügbar und in seinem Umfang verfügbar ist. –

Im Allgemeinen, wenn Ihre Abhängigkeiten in eine Richtung gehen, sind Sie in guter Form. Die Faustregel lautet, dass Abhängigkeiten vom Benutzer zurück in die Persistenz gehen (z. B. Darstellungsschicht -> Dienstschicht -> Persistenzschicht), aber wenn Sie beide Richtungen haben oder wenn Sie Ebenen überspringen, können Sie Probleme haben. – Paul

Repositories sind Teil der Domäne.

Zwischen der Reduzierung von Baugruppenreferenzen und der Minimierung der Anzahl von Projekten besteht immer eine Spannung. Das heißt, Sie können festlegen, dass jede Assembly weniger Abhängigkeiten referenziert, indem sie die Funktionalität in feinkörnigere Assemblies aufteilt. Eine übermäßige Aufteilung eines Projekts in viele Baugruppen erfordert jedoch einen höheren Verwaltungsaufwand.

Ein weiterer erwähnenswerter Punkt ist, dass Authentifizierung einige Seiten hat. Man verwaltet das Modell um Benutzer, Rollen, Berechtigungen, etc. - das ist ein Domänenproblem. Der andere ist Schnittstelle mit dem Kontext der Ausführung (ob dies eine ASP.Net App ist, WinForms, etc.) - das ist ein Infrastrukturproblem. Folglich habe ich am Ende einen kleinen Dienst in meinem MVC-Projekt oder WinForms-Projekt, der Funktionen wie das Setzen von Formularauthentifizierungscookies oder das Setzen des aktuellen Threadprinzips usw. ausführt.

Quelle

2010-12-03 20:58:18

Hervorragende Erklärung. – Paul

Die Separated interface pattern besagt, dass Ihre Modelle und Repository-Schnittstellen in sein sollten eine separate Assembly, abgesehen von der GUI und der eigentlichen Repository-Implementierung. Dies ist in der Lage, Implementierungen später zu wechseln und das Testen zu vereinfachen.

Ich hätte kein Problem damit, die Schnittstellen zusammen mit den Repository-Schnittstellen und der eigentlichen Implementierung im mvc-Projekt oder im Repository-Projekt zu setzen. Es ist ziemlich einfach, Sachen später zu verschieben, wenn Sie einen IoC-Behälter benutzen.

Quelle

2010-12-03 21:09:38 jgauffin

ASP.NET MVC - Wohin geht die Authentifizierungsschicht?

Antwort

Verwandte Themen