Wozu kann ich POCO verwenden?

POCO-Standards für "Plain Old Clr Object". Es bezieht sich auf einen Stil der ORM-Architektur, bei dem alle Arbeiten zum Persistieren und Laden der Daten aus dem Datenspeicher vom System ausgeführt werden, ohne dass das Objekt selbst weiß, was mit ihm geschieht. Dies bedeutet, dass das ORM vollständig einfache Objekte unterstützen kann, die in keiner Weise mit dem ORM modifiziert wurden. Ein ORM, das die Persistenz von POCOs unterstützt, erfordert nicht, dass Sie die Klasse von einer bestimmten Basis erben, eine Schnittstelle implementieren oder Methoden mit Attributen versehen.

Das Gegenteil davon (manchmal als Data Access Objects oder DAO bezeichnet) ist, wenn der gesamte Speicher vom Objekt selbst verarbeitet wird, er genau weiß, wie er serialisiert und gespeichert wird und wie er sich bei Bedarf selbst lädt. In diesem Fall sollten die Objekte ausschließlich zur Übertragung der Daten verwendet werden und keine der Geschäftslogik des Systems repräsentieren.

In Wirklichkeit ist dies eher ein Spektrum mit diesen beiden Situationen an jedem Ende. Viele ORMs befinden sich irgendwo in der Mitte, was erfordert, dass die Persistenz außerhalb der Klasse gehandhabt wird, erfordern aber oft auch, dass einige Metadaten oder Schnittstellen in den Klassen implementiert werden, um die Dinge zu unterstützen.

Die EF (v1) unterstützt keine POCOs. Die Objekte müssen verschiedene Schnittstellen implementieren (um eine Benachrichtigung über Eigenschaftswerteänderungen usw. zu liefern), um durch das Rahmenwerk persistent zu sein. Ich glaube, es gibt Addon-Frameworks , dass versucht wurde, der EF POCO-Unterstützung hinzuzufügen, aber ich weiß nicht, wie erfolgreich sie sind. Die EF in. net 4.0 wird POCO-Unterstützung haben.

POCO wird oft als gut angesehen, weil es eine starke Trennung von Bedenken ermöglicht. Sie können Ihre Datenobjekte so definieren, dass sie absolut keine Kenntnisse über den Mechanismus haben, der zum Speichern dieser Datenobjekte verwendet wird. (Es macht es also leicht, den Speichermechanismus für etwas anderes in der Zukunft auszuschalten). Es bedeutet auch, dass Sie Ihre Datenobjekte nicht mit Rücksicht auf die Datenbank / das Framework entwerfen müssen, das für die Speicherung verwendet wird.

POCO ist nur "Plain Old CLR Object". Es ist nur eine Standardklasse, jede Standardklasse.

In Bezug auf EF beziehen sich Leute darauf, EF so konfigurieren zu können, dass sie eigene Klassen (nicht direkt von EF erzeugt) in der Datenbank speichern.

POCO ist nur eine normale Klasse, ohne zusätzliche Schnittstellen oder Basisklassen, damit es in diesem Kontext mit Ihrer Datenbankschicht funktioniert.

Vorteil sind: 1) keine Abhängigkeiten von dieser bestimmten Datenbankschicht, so dass Sie sie gegen eine bessere austauschen können (d. H. NHibernate), ohne dass Sie irgendetwas anderes als die Datenbankschicht ändern müssen.

2) es macht es einfacher zu Unit Tests Ihrer Klassen.

3) kein Kesselblech-Code um zu benachrichtigen, wenn sich eine Eigenschaft geändert hat etc. einfach nur Getter und Setter.

Idealerweise werden Ihre Domain-Objekte aus dem ORM geladen, ohne dass das Objekt sagen muss, wie es geladen wird, wie Änderungen verfolgt werden oder wie es gespeichert wird.

NHibernate macht hier eine sehr gute Arbeit, die einzige Voraussetzung ist, dass Sie alle Eigenschaften / Methoden virtuell machen müssen, das ist viel besser als jede harte Abhängigkeit.

POCO sind Klassen, die entwickelt wurden, um Daten innerhalb Ihrer Anwendung zu übertragen (d. h. Daten von der Datenschicht zur ui-Schicht zu bewegen). Sie entkoppeln auch die Struktur Ihrer Anwendung vom Schema Ihrer Datenbank.

Bei kleinen Projekten ist das keine große Sache, aber wenn das Projekt wächst, neigt das Objektmodell (wie Sie Ihre POCOs entwerfen) dazu, vom Datenbankschema abzuweichen.

Andere Methoden, die normalerweise in .NET verwendet werden, sind DataTables und DataSets. In der Regel werden die Daten mithilfe des Spaltennamens abgerufen. Dadurch koppeln Sie den Spaltennamen in Ihrer Datenbank. Wenn sich der Spaltenname in der Datenbank ändert, bricht der Code ab.