1

Ich baue eine Anwendung, die MVC 2, mit EF 4 verwendet, das Repository-Muster und poco verwendend. Ich möchte eine Anmeldeseite für Kunden erstellen. Wo sollte die Funktionalität leben, die Dinge wie Passwortrichtlinien überprüft, Gültigkeit und alle anderen Dinge Login-bezogen. Würde dies innerhalb der von POCO generierten Customer Entity stattfinden, sollte ich eine separate Login-Klasse erstellen oder etwas anderes?Position des Passworts funktionalitly in DDD

Dank

Stu

Antwort

2

Unter DDD, könnte diese Funktionalität als Service implementiert werden, da es nicht die in Eigenverantwortung des Kunden ist, sich zu authentifizieren. Sie können eine Definition von Service here lesen.

+0

Also, anstatt diese Funktionalität in der Domain-Ebene zu platzieren, sagen Sie, es wäre besser in einer separaten Service-Schicht platziert? – hoakey

+2

Nein, keine Service-Schicht, ein Domain Service (im Kontext von DDD). Es ist ein Weg, eine Art des Umgangs mit Operationen zwischen Entitäten darzustellen, die keine ausschließlichen Verantwortlichkeiten einer dieser Entitäten sind. Mehr dazu [hier] (http://devlicio.us/blogs/casey/archive/2009/02/17/ddd-services.aspx). – CGK

+0

+1 - ich stimme zu. Dies ist eine Authentifizierung, die nicht Teil der Domäne ist, sondern Teil der Darstellung der Domäne als Webanwendung. Sollte Domain-Service sein. – RPM1984

1

Check Dieser Link, es gibt einige Punkte, die Ihnen helfen könnten.

Erstellen Sie ein separates Modell für Password und User, übergeben Sie sie an den Domain Service und lassen Sie das Customer Repository die andere Aufgabe behandeln.

Zusätzlich haben Sie referred Sharp Architecture. dies baut auf MVC + DDD + NH + POCO auf. Dies wird Ihnen kurz darüber geben, wonach Sie suchen.

+0

Strewth, das sieht alles ziemlich überwältigend aus. Mit Ihren Kenntnissen von Sharp Architecture sollten Sie sich insbesondere etwas zu meiner Login-Frage ansehen? – hoakey

Verwandte Themen