what is Entity Framework with POCO

Question

What is the benefit of using POCO? I don't understand the meaning of Persistence Ignorance, what does this mean? That the poco object can't expose things like Save? I can't wrap my head around this POCO that there's alot of buzz around.

What is the difference with the EF generated entities and POCO?

Solution 1

POCO stands for "Plain Old C# Object" or "Plain Old CLR Object", depending on who you ask. If a framework or API states that it operates on POCO's, it means it allows you to define your object model idiomatically without having to make your objects inherit from specific base classes. Generally speaking, frameworks that work on POCO's allow you greater freedom and control over the design and implementation of your classes, because they have fewer requirements to work correctly.

Persistence ignorance means that, as much as possible, anything in your code operating at the business logic layer or higher knows nothing about the actual design of the database, what database engine you're running, or how or when objects get retrieved from or persisted to the database. In the case of the MEF, persistence ignorance is attained by working on POCO's and using LINQ to perform queries (i.e., not requiring the user to create any SQL queries to retrieve the desired objects).

It's an open question, but it's generally agreed that under most circumstances, the domain objects (or business objects - either way, the POCO's mentioned above) should be ignorant of persistence logic. Meaning, instead of calling MyBusinessObject.Save(), you have a IO manager or adapter class, and you call Manager.Save(MyBusinessObject). In this way, you avoid exposing persistence semantics on your business objects - you get better separation of concerns that way.

Solution 2

POCO = Plain old CLR Objects.

Plain old CLR (i.e. C# or VB) objects means I can speak C# or VB the whole time I am writing my program, and not have to worry about esoteric database language like

UPDATE MYTABLE SET MYFIELD1 = @MYPARAMETER1, MYFIELD2 = @MYPARAMETER2 BLAH BLAH

EF Generated entities == POCO connected (indirectly) to a database.

Solution 3

POCO class is the class which doesn’t depend on any framework specific base class. It is like any other normal .net class that is why it is called “Plain Old CLR Objects” These POCO entities (also known as persistence-ignorant objects) support most of the same LINQ queries as EntityObject derived entities.

Solution 4

POCO = Plain old CLR Objects

POCO Benefits:

Technology Agnosticism is a bliss: This concept is usually revolving around PI (Persistence Ignorance), but it is not only that. Persistence Ignorance means that your entities should be cleared of any persistence related code constraints that a framework - usually an ORM - forces on you. This is, for e.g. if you have attribute level mapping where those attributes are not part of your domain but are there just because some framework wants them to be there, then your domain is not persistence ignorant. Sidar said here

View more solutions

Comments

[Matti]

Plain Old CLR Objects is closer to the truth. This works fine with VB.Net, or any other CLS-compliant languages.

[pdiddy]

But with EntityFramework generated entities, we do get this seperation already with the classes generated that inherits from the ObjectContext do to the persistence and classes representing the entity. I'm reading the article on msdn magazine on EF 4.0 and there is a section about POCO, in the article, the writer creates object from scratch ... Can't we use the entities generated ? Aren't they POCO?

[Dathan]

Can you post a link to the article? If your framework requires your entity classes to derive from a particular base class or include framework-specific attributes or implement framework interfaces, then it doesn't support POCO's. If EF 4.0 doesn't place a base class or attribution requirement on its entity classes, then it supports POCO's. Note that this restriction doesn't apply to classes that are specifically intended to manage persistence semantics - they have to be coupled to the persistence, and talking about POCO's there is missing the point.

[marc_s]

EF will by default use EntityObject as its base class for all its entities --> definitely not POCO. BUT: with EF4, you do have the option to turn on POCO support, in which case your classes don't derive from any specific base class, don't need to implement any specific interface, and don't need any attributes either --> pure POCO.

[pdiddy]

Oh ok I see. So because the Entity generated by EF derives from the EnttiyObject, it makes them not POCO. The article is here : msdn.microsoft.com/en-ca/magazine/ee336128.aspx So that is why in the article it turns off the Code Generation and creates his own class for each Entity. So is there a way to have visual studio generates the POCO object. I guess through some T4 templates. How is POCO object a better design than using directly the EF entity?

[littlechris]

See here for T4 auto generating of POCOs for EF blogs.msdn.com/adonet/pages/…

[Pang]

Link at end of answer is dead - "404 Not Found".