Compare Entity Framework 4 objects to ADO.NET C# POCO Entity Generator objects

I really have two questions:

1. What is the difference between an Entity Framework Entity object and an ADO.NET C# POCO Entity.
2. Do I have updating a record using a repository correct below?

If y开发者_StackOverflow中文版ou turn off code generation, then add the ADO.NET C# POCO Entity Generator, it provides a nice class representation of your Entity Framework 4 objects. The idea is that (from here):

The POCO Template can be used to generate persistence ignorant entity types 
from an Entity Data Model.

However, these objects have the relations between objects as well as a link back to the database. For example, you can pull one out of your repository, alter it, then save changes at the repository or unit of work level, and it saves the content to the database.

So my question is what is different between a native Entity Framework object and these POCOs generated using this tool?

This is what I think when I update a record using a repository. Is this wrong?

1. Request a POCO from the repository.
2. The Repository loads the records from the data context, creates a new POCO for each record found, copies the values from the Entity Framework objects to the POCOs, and returns a collection of the new POCOs.
3. Changes are made to these POCOs outside of the repository, then the POCOs are submitted back to the repository using something like Save(POCO).
4. The repository loads the matching records from the database and copies the POCO properties to the Entity Framework objects.
5. One calls Save using either the repository object or unit of work object.

In case of POCO generator the generated entity classes (eg, Employee, Company etc.) don't derive from any special class (hence called Plain Old). Whereas in case of entityobject generator, the entity classes derive from the special 'EntityObject' class, which provides certain capabilities.

The objective behind having POCO classes is to do away with the DB specific concerns of an entity. Thus keeping our domain model unaware of DB/persistence operations.

POCO means that you have a plain old CLR class which is not polluted by special constructs related to the persistance. Entity objects are derived from EntityObject class and they use a lot of classes and attributes directly related to entity framework. When using EntityObjects you are making your code fully dependent on entity framework.

What you describe in your repository was used in EFv1 to achieve POCO approach. Currently you can use POCOs directly. POCOs don't have any relation to the database. In some scenarios POCOs are dynamically proxied by EF dependent constructs but this happens during runtime so it doesn't pollute your code.