0
Ich versuche, mehr über Domain Driven Development einschließlich der Repository-Muster, Unit of Work, etc. und Lesen von Fowlers Buch und Evans ... aber gerade erst begonnen, dies zu tun. Ich möchte eine App einrichten, um meine Data Layer Logik und Struktur von meinem BL (Domain) zu trennen.Linq zu SQL mit Repository-Muster und DDD
Wenn ich LINQ to SQL verwende, nehme ich an, dass es einfach meine eng verbundenen Tabellenobjekte erzeugt, die nichts mit DDD zu tun haben, weil ich dann ein Repomuster erstellen und Probleme zwischen meinem DL (LINQ to SQL) trennen kann) und meine BL Logik ... ist das richtig?
Dank ... ok, aber Domain-Objekte sind Ihre BL Klassen Rechte? Nur ein anderer Begriff für Business-Schicht-Klasse/Objekt ... nennt es Domain-Objekte/Klassen. Also das Mapping, wenn Sie die LINQ to SQL-Route gehen, müsste von Ihnen erledigt werden ... benutzerdefinierten Code richtig? – PositiveGuy
Ja - Domain-Objekt == Business-Objekt - sie sind die Basis "Dinge", die Sie Ihr Domian herum aufbauen - Dinge wie Mitarbeiter und Bestellungen und Kunden usw. ... Wenn Sie die Linq zu SQL-Route Ihre Domain/Business-Klassen gehen sollte für Sie generiert werden - ich weiß, in der Entity Framework machen sie eine gute Arbeit machen POCO-Objekt, das Sie problemlos erweitern können und IIRC Linq to SQL macht das gleiche. –
warten Sie, so haben Sie Ihre DL-Klassen (DTOs), Ihre BL-Klassen (Workflow-Logik) und Presentation Layer. Worüber sprichst du dann hier, wenn du allgemein die Domain sagst? Ist das nicht deine BL? Und warum sollte das Entity-Framework automatisch Ihre BL-Objekte erstellen? Diese sind sehr benutzerdefiniert für Ihre Geschäftsdomäne und Workflow-Logik, die Sie benötigen, um diese in Ihrem PL zu verwenden ... also können Sie wiederholen, was Sie gesagt haben ... Ich bin ein bisschen verwirrt. – PositiveGuy