Wofür kann ich POCO verwenden?

Question

Ich habe ein paar Artikel über POCO im Rahmen von enttity gelesen, verstehe aber immer noch nicht, wofür ich es verwenden kann. Wie kann POCO meinen Projekten nützen?

Answer 1

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 vollständige Gegenteil davon (manchmal auch Data Access Objects oder DAO genannt) ist, wenn der gesamte Speicher vom Objekt selbst verwaltet wird. Er weiß genau, 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 Geschäftslogik des Systems darstellen.

In Wirklichkeit ist dies mehr ein Spektrum mit diesen beiden Situationen an jedem Ende. Viele ORMs befinden sich irgendwo in der Mitte, was erfordert, dass die Persistenz extern zu der Klasse gehandhabt wird, erfordern aber häufig auch, dass einige Metadaten oder Schnittstellen in den Klassen implementiert werden, um die Dinge weiter 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, die versuchen, POCO Unterstützung der EF 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, da 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, in dem sie gespeichert werden.

Answer 2

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

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

Answer 3

POCO sind Klassen, die entwickelt wurden, um Daten innerhalb Ihrer Anwendung zu übertragen (d. H. Daten von der Datenschicht zur ui-Schicht zu verschieben). 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.

Answer 4

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 Datenbank-Schicht, so können Sie es für eine bessere (d. H. NHibernate) austauschen, ohne jemals etwas anderes als die Datenbank-Schicht zu ändern.

2) Es erleichtert das Testen der Klassen.

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

Idealy Ihre Domain-Objekte werden aus dem ORM geladen, ohne dass das Objekt in jeder sagen müssen, wie es geladen wird, wie sich Änderungen verfolgt werden oder, wie es gespeichert usw.

NHibernate macht einen sehr guten Job bei dieser Die einzige Voraussetzung ist, dass Sie alle Eigenschaften/Methoden virtuell machen müssen, das ist viel besser als jede harte Abhängigkeit.