Programming Entity Framework - Cdn.oreilly.com

More documents

Recommendations

Info

13 Creating and Using POCO Classes When it was first released, Entity Framework was roundly criticized by agile developers. These developers hold the tenets of domain-driven development and testability very high. The classes generated from the Entity Data Model (EDM) are very tightly bound to the Entity Framework APIs by either inheriting from the EntityObject or implementing interfaces that allow the classes to participate in change tracking and relationship management. The problem with this is that it is extremely difficult to write unit tests with these classes. Unit tests need to emulate persistence. In other words, during a test, instead of literally querying the database, a test might just supply some fake data to a class, or instead of sending data to the data store, a test might say “OK, let’s pretend that part just happened and we’ll move on now.” In addition to the problem the dependent classes create for testing, it also makes it difficult for developers to change their backend infrastructure if needed. For example, an application might be written using another object relational mapping tool, such as NHibernate. If a developer wanted to switch to the Entity Framework, version 1 made it very difficult to just take the existing classes and put Entity Framework behind. The developer would be required to make some major changes to the classes, binding them tightly to Entity Framework. The Entity Framework team listened to and learned from the agile community and added a number of new mechanisms for supporting agile development. One of these is support for Plain Old CLR Objects (POCO). POCOs are classes that remain free from a backing infrastructure, such as Entity Framework. A POCO class would not inherit from Entity Framework’s EntityObject. But as you’ve seen, the EntityObject performs all of the important work for providing relationship and change tracking information to the context. In order to remove the dependency on EntityObject, the Entity Framework gained some new functionality that allows the ObjectContext to acquire relationship and change tracking information from classes that do not inherit from EntityObject. In fact, as you’ll see, it can do so with classes that have no knowledge at all about the Entity Framework.
In addition to POCO support, the team added two other important features for agile developers. One is support for model-first development which allows developers to begin a project with a model and use that model to create a database. The other is called codefirst development. You’ll learn more about model first and code first, as they are called, in Chapter 23. Do be aware that code first is still a work in progress and is available as part of a separate download called the Entity Framework CTP. In this chapter, you’ll learn the basics of how to create and work with POCO objects in Entity Framework, and later chapters in the book will leverage POCO classes as well as those that inherit directly from EntityObject. Chapter 22 is devoted to using Entity Framework POCO classes in a more agile architecture using repositories and unit testing. Creating POCO Classes POCO classes work in conjunction with a model in that they must mirror the entities in the model. To begin this discussion, we’ll return to SampleModel, the very simple model and database that you used in the first few chapters of the book. Let’s create the model first and then the classes as it will be helpful to point out how they relate to one another. It is just as likely that you will create the classes first. Start by creating a new Console Application project. Then add a new Entity Data Model based on ProgrammingEntityFrameworkDB1. Name the EntityContainer POCOEntities and select all tables. Now you are back to your simple model. There are a few rules that you need to follow when creating classes that will interact with Entity Framework. The first is that the class and property names should align with the model. For this example, we’ll just follow the existing model to determine the names and structure of the classes. Add two new class files to the project, called Contact.cs and Address.cs. Next, add properties to the Contact class for every property in the Contact entity. Be sure to mimic the names as well as the types, with one caveat. The Addresses navigation property returns an EntityCollection which is a very constrained type. In your class, use an ICollection to return the related collection. An ICollection will give you ultimate flexibility when you use the class. Figure 13-1 serves as a reminder of what the entities look like in the model.
Page 1 and 2: Free Sampler
Page 3 and 4: Programming Entity Framework by Jul
Page 5 and 6: The EDM Within the Entity Framework
Page 7 and 8: Retrieving a Single Entity with Get
Page 9 and 10: Breaking Apart the ObjectQuery 222
Page 11 and 12: Using a New EntityDataSource to Add
Page 13 and 14: Insert, Update, and Delete Function
Page 15 and 16: Digging Through ObjectStateEntry 53
Page 17 and 18: 19. Using Your Own Custom Classes .
Page 19: Designing the Service Interface 725
Page 23 and 24: using System.Text; namespace Chapte
Page 25 and 26: } } public ObjectSet Addresses { ge
Page 27 and 28: } If you run the code now, you will
Page 29 and 30: Using Proxies to Enable Change Noti
Page 31 and 32: Figure 13-2. A high-level view of t
Page 33 and 34: Rule 2: To enable lazy loading on a
Page 35 and 36: using System.Collections.ObjectMode
Page 37 and 38: Modifying the POCO Template Althoug
Page 39 and 40: The next step is to modify the temp
Page 41 and 42: get; set; } public string Street1 {
Page 43: Want to read more? You can find thi

Programming Entity Framework - Cdn.oreilly.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?