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…

Question

Exhibit

Options

• AEntity objects are being used. => A, B out
• BThe DAL always have to be updated not only when you are retrieving the data. => D out
• CCreate persistent-aware objects.
• DCreate persistent-ignorant objects.

• A
  5% (2)
• B
  9% (4)
• C
  84% (36)
• D
  2% (1)

Explanation

This will be achieved by non-POCO i.e. persistant aware objects or an observable collection of 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 All classes must have a default constructor 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

No community discussion yet for this question.