The information in this post is out of date.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

 

In Entity Framework 3.5 (.NET 3.5 SP1), there are more than a few restrictions that were imposed on entity classes. Entity classes in EF needed to either be sub classes of EntityObject, or had to implement a set of interfaces we collectively refer to as IPOCO – i.e. IEntityWithKey, IEntityWithChangeTracker and IEntityWithRelationships. These restrictions made it difficult if not downright impossible to build EF friendly domain classes that were truly independent of persistence concerns. It also meant that the testability of the domain classes was severely compromised.

All of this changes dramatically with the next release of Entity Framework: 4.0 (.NET Framework 4.0). Entity Framework 4.0 introduces support for Plain Old CLR Objects, or POCO types that do not need to comply with any of the following restrictions:

 

  • Inheriting from a base class that is required for persistence concerns
  • Implementing an interface that is required for persistence concerns
  • The need for metadata or mapping attributes on type members

For instance, in Entity Framework 4.0, you can have entities that are coded as shown:

    public class

Customer

    {
        public string CustomerID { get; set; }
        public string ContactName { get; set; }
        public string City { get; set; }
        public

List

<

Order

> Orders { get; set; }
    }

 

    public class

Order

    {
        public int OrderID { get; set; }
        public

Customer

 Customer { get; set; }
        public

DateTime

 OrderDate { get; set; }
    }

You can then use the Entity Framework to query and materialize instances of these types out of the database, get all the other services offered by Entity Framework for change tracking, updating, etc. No more IPOCO, no more EntityObject - just pure POCO.

Keep in mind that this is an extremely simplistic example, and intentionally so. There is much more here than meets the eye  – I am sure that it brings up at least a few questions about what is possible and what isn’t possible with POCO entities – for instance:

  • Do I need to have public getters/setters for scalar and navigation properties?
  • Will I get Lazy Loading? How does explicit loading work?
  • How does relationship fix-up work with POCO?
  • What does this mean for code generation done within Visual Studio?
  • How does this fit in with the repository pattern?

What about Complex Types? Serialization? Change Tracking? Add/Attach…. The list goes on….

These and many other questions and concerns will be answered in our in-depth series on POCO that we are working on publishing in the coming weeks.

And by the way – did I just mention Lazy Loading? Watch for a sneak preview on that tomorrow!

- Faisal Mohamood
Program Manager, Entity Framework