Was sind die Vor-/Nachteile der Rückgabe von POCO-Objekten aus einem Repository als EF-Entitäten?

Question

Nach der Art, wie Rob es tut, habe ich die Klassen, die vom SQL-Wizard Linq generiert werden, und dann eine Kopie dieser Klassen, die POCOs sind. In meiner Repositories kehre ich diese POCOs anstatt die Linq to SQL-Modelle:

 
return from c in DataContext.Customer 
     where c.ID == id 
     select new MyPocoModels.Customer { ID = c.ID, Name = c.Name } 

Ich verstehe, dass der Vorteil davon ist, dass die POCO-Modelle einfacher so instanziiert werden kann dies wird mein Code mehr prüfbar machen.

Ich bin jetzt von Linq zu SQL über Entity Framework und ich bin etwa auf halbem Weg durch ein EF-Buch. Es scheint, dass es eine Menge Güte gibt, die ich verlieren werde, indem ich POCOs aus meinen Repositorien zurückgebe, anstatt die EF-Entitäten.

Ich habe noch nicht wirklich angenommen Unit-Tests, so dass ich, wie ich fühle mich viel Zeit verschwenden diese zusätzlichen POCOs erstellen und den Code zu schreiben, sie zu füllen, wenn alles, was ich prüfbar Code zu sein scheinen zu gewinnen, noch Ich werde auch viele Vorteile des EF verlieren, weil ich meine Objekte nicht verfolgen kann.

Hat jemand einen Rat für ein relatives newb zu all diesen ORM/Repository Sachen?

Anthony

Answer 1

Ein anderer Grund, warum Leute die automatisch generierten Objekte nicht mögen (in LINQ to SQL zum Beispiel) ist wegen ihrer eingebauten "Magie". Normalerweise ist die Magie unsichtbar und man merkt es nie, aber wenn man versucht, Dinge wie eines dieser Objekte zu serialisieren und es dann zu deserialisieren (zum Beispiel bei der Verwendung von Webdiensten), ist seine interne Verbindung zur Datenquelle unterbrochen und spezielle Hacks müssen eingesetzt werden, um "die Magie zurückzubringen".

Mit POCOs müssen Sie sich nicht um solche Dinge kümmern und können eine bessere Trennung zwischen Ihren Daten- und Service-Schichten erzielen. Der Nachteil ist natürlich, dass man viel langweiliges POCO -> magisches Objekt und magisches Objekt -> POCO-Umwandlungscode schreiben muss. Aber am Ende denke ich, dass es sich in der Regel lohnt, besonders für große oder komplexe Projekte.

Answer 2

Der Hauptgrund ist, dass viele Menschen mit einer bestimmten Mentalität ihr Modell entwickeln mögen: wie DDD zum Beispiel. Sie möchten vielleicht ein bestimmtes Muster (wie Spec oder State) für Dinge wie Status (anstelle von Enums) verwenden - oder Sie möchten eine Factory für Instanziierung verwenden.

OO bricht, wenn Sie versuchen, Tabellen als Objekte zu verwenden, wenn die Dinge komplexer werden. Einfache Websites funktionieren in Ordnung - aber wenn Sie zu großen großen Dingen kommen, wird es hässlich.

Also - wie immer - es hängt davon ab, was Sie denken, dass Ihr Projekt wird.

Answer 3

Meine Erfahrung ist, dass, wenn Sie einige komplexe Abfragen .INCLUDE Methode beginnen writting wertlos ist und Sie werden sich finden entweder:

a) Writting viele Anfragen die gewünschten Daten oder b zu erhalten) zu missbrauchen von anonyme Typen, um die Daten in einer einzigen Abfrage zu laden und dann viel Code zu schreiben, nur um diese Daten an Ihre Entitäten zu übergeben.

POCOs sind der Weg zu gehen, IMHO.