You are designing a Windows Presentation Foundation (WPF) application by using Microsoft .NET Framework 4, Microsoft Visual Studio 2010, and Microsoft SQL Server 2008.

You have designed the application to use the ADO.NET Entity Framework for the Data Access Layer (DAL).

You have designed the user interface (UI) of the application by using the Model-View-ViewModel (M-V-VM) pattern.

The middle tier of the application is designed by using Windows Communication Foundation (WCF).

The database schema changes often. The DAL entity objects are required to be referenced from the middle tier and the ViewModel layer of the UI.

You need to ensure that the DAL entity objects are updated when the database schema changes.

What should you do?

A.
Create an observable collection of objects.

B.
Create typed DataSets.

C.
Create persistent-aware objects.

D.
Create persistent-ignorant objects.

Explanation:
This gives us:
Entity objects are being used. => A, B out
The DAL always have to be updated not only when you are retrieving the data. => D out This will be achieved by non-POCO i.e. persistant aware objects or an observable collection of objects.
Since it’s specified we are using Entity Objects we will not have to use an observable collection. My answer is therefore C.

POCO is often considered good because it allows for a strong separation of concerns. You can define your data objects to have absolutely zero knowledge of the mechanism that will be used to store them. (So it makes it easy to switch out the storage mechanism for something different in the future). It also means you don’t have to design your data objects with any consideration for the database/framework that is used to store them.
persistence ignorant
must have a default constructor
All classes
Some features don’t work unless classes are unsealed and all members are virtual Object identity doesn’t work properly unless you abuse Equals/GetHashCode (Aside: Before anybody gets upset, I don’t mean to pick on NHibernate here, it’s just a frequently quoted example of a framework that supposedly permits persistence ignorance. I’m sure similar arguments could be applied to other ORMs that claim the same.)
Now although the class in itself does not have any persistence-framework-specific attributes or base classes etc., to me it is not really “persistence ignorant” because it must follow a set of design guidelines to facilitate use by the chosen persistence framework