2010-12-30 5 views
3

ich auf all diesen Themen eine crapload Lesen:Aussortieren POCO, Repository-Muster, Arbeitseinheit und ORM

POCO
Repository Pattern
UOW
ein ORM-Mapper verwenden

ok Ich sehe die grundlegenden Definitionen von jedem in Büchern, etc., aber ich kann dies nicht alle zusammen visualisieren. Bedeutung einer Beispielstruktur (DL, BL, PL).

Also, was haben Sie Ihre DL-Objekte, die Ihre CRUD-Methoden enthalten, dann Ihre BL-Objekte, die mit einem ORM zurück auf Ihre DL-Objekte "gemappt" werden? Was ist mit DTOs ... sie sind deine DL-Objekte richtig? Ich bin verwirrt.

Kann jemand wirklich alles zusammen erklären oder mir Beispielcode schicken? Ich versuche nur, das zusammen zu bringen. Ich bestimme, ob LINQ zu SQL oder EF 4 (nicht sicher über NHibrernate noch gehen).

Nur nicht die Konzepte wie in physikalischen Ebenen und Code-Ebenen hier und was jeder Typ von Objekt enthält (nur Eigenschaften für DTOs und CRUDs für Ihre DL-Kernklassen, die die Tabellenfelder übereinstimmen ???).

Ich brauche nur ein wenig Anleitung hier. Ich lese Fowlers Bücher und lese Evans, aber noch nicht alle da.

+1

Viele Fragen hier; was es mir schwer macht zu antworten. Lesen Sie etwas mehr (zum Beispiel die Links, die Vsevolod in seiner Antwort geschrieben hat), probieren Sie einige Konzepte aus und stellen Sie dann eine bestimmte Frage. Dann können wir Ihnen besser helfen. Literaturweise würde ich sagen, dass Sie auf dem richtigen Weg sind; aber tatsächlich: es ist eine Menge zu begreifen. – Marijn

Antwort

6

Ich werde davon ausgehen, dass DL - Domain Layer, BL - Business Layes und PL - Persistence Layer.

Wenn Sie eine einfache CRUD-Anwendung benötigen, sollten Sie keine DDD-Prinzipien verwenden. Verwenden Sie DDD, wenn Sie ein komplexes Domänenmodell implementieren möchten.

In DDD werden Sie DL und BL kombiniert mit ALLEN Logik innerhalb Ihrer Domäne Objekte/Dienste. Andernfalls erstellen Sie eine Anemic Domain Model. Vermeiden Sie Setter für Eigenschaften und ändern Sie Ihre Objekte nur über Methodenaufrufe wie ChangeAddress statt obj.Address = newAddress oder Activate statt obj.Active = true.

Datentransferobjekte sollten nur für die Kommunikation mit externen Diensten/UI verwendet werden. In Ihrer Domain werden nur Domain-Objekte verwendet.

Ich empfehle, task-basierte UI zu verwenden.

Welche Persistenztechnologie in Persistence Layer verwendet wird, hängt von Ihren Anforderungen ab. Bevor Sie sich für SQL RDBMS entscheiden, werfen Sie einen Blick auf die Wikipedia-Seite Object-relational impedance mismatch.

Für die Durchführung Proben bitte Fragen prüfen:

  1. Are there any open source projects using DDD (Domain Driven Design)?
  2. Good Domain Driven Design samples
  3. .NET DDD Example
+0

genial, das ist nur der Rat, den ich suche. Jetzt kenne ich jemanden, der für eine.com verwendet LINQ to SQL, um ihre Data Layer (DL) -Klassen (Crud-Methoden) auszugeben, aber dann ein Repository/Unit of Work-Muster für die Behandlung der Domänenlogik und Persistenz zu verwenden. Ich meine, sie benutzen beide, denke ich ... das ist es, was ich hier zu entscheiden versuche. Aber mit DDD ist nur gut, nicht wahr? weil Sie Ihre BL (Business Layer) -Logik nicht fest an die Persistenzschicht binden, also würde ich denken, dass es für jedes System gut ist, aber dann sagen Sie, dass es einen Leistungseinbruch für die Verwendung von DDD geben könnte ?? – PositiveGuy

+0

Ich habe für ein paar .comS gearbeitet und wir haben nicht DDD, nur eng gekoppelt DL an DB entweder durch die Codierung von benutzerdefinierten Entitäten oder so etwas wie CodeSmith Vorlagen, um Entitäten auszustoßen. Aber jetzt habe ich Orte gesehen, mit denen ich interviewt habe, die auf DDD schwören und alle E-Commerce-.com sind. Ich arbeite an meinem eigenen .com auf der Seite, deshalb ist das alles überwältigend für mich. Ich versuche, hier etwas weiter zu kommen, um meine App viel flexibler, sauberer und erweiterbarer zu machen, anstatt das streng starke Paar von DL zu DB zu machen ... aber dann bringt DDD die Abstraktion von BL nach DL mit ein ? – PositiveGuy

+0

Wenn ich eine saubere Trennung von BL zu DL halte, könnte ich meine DL im Prinzip austauschen, wenn ich es auch in Zukunft brauche ... also ist das nicht das, worum es bei DDD geht? Dass du BL Logik bist, ist nicht eng mit deinem DL verknüpft. – PositiveGuy