.NET Database Technologies: Entity Framework additional notes – part 2

1. .NET Database Technologies: Entity Framework additional notes – part 2

2. EF1 => EF4 • “The 1.0 release of the Entity Framework was not a resounding success – developers found themselves fighting the framework” • EF4 gives you the choice of how to work • Database-first, model-first, code-first • Supports POCO entities for Persistence Ignorance

3. POCO support • EF1 entity classes inherit from EntityObject • Difficult to separate concerns in application • Classes are difficult to unit test • For unit testing, want to “fake” persistent storage • Difficult to switch DAL technology • Can’t take existing classes and use EF1 • Need to redesign classes significantly to bind them to EF • EF4 allows you to use POCOs • Model classes can be completely ignorant of persistence mechanism

4. POCO classes • POCO classes must work in conjunction with EDM • Must mirror entities defines in EDM • However, EDM does not generate the classes • Set Code Generation Strategy to none in designer properties • Two ways to create classes • Write POCO code by hand • Use a T4 Template • Microsoft ADO.NET C# POCO Entity Generator • Download from www.visualstudiogallery.com • Right-click EDM designer surface and select Add Code Generation Item • Creates template for generating POCOs to match EDM

5. T4 • Text Template Transformation Toolkit • Code generation tool built into Visual Studio • Can be used in many different code generation scenarios • Template file has .tt extension • When a project has a .tt file, the template is processed at build time • Generated code file(s) associated with template in Solution Explorer, but can be moved elsewhere if required

6. Managing POCOs • Need to create a custom ObjectContext class • Should have an ObjectSet for each entity type • Needs to know name of EDMX file (passed in as a constructor parameter) to allow it to access mapping and storage information

7. Issues with POCOs – change tracking • Change tracking • Classes derived from EntityObject constantly communicate with ObjectContext • POCOs can’t do this • ObjectContext has to track changes to POCOs: • DetectChanges method • SaveOptions -> DetectAllChanges forces call to DetectChanges before saving • Default behaviour

8. Issues with POCOs – loading related data • EntityObject can load related data with Load method • e.g. employee.AddressesReference.Load() • Navigation property also has an EntityReference property • POCO does not have EntityReference properties • Need to load related data from context • e.g. context.LoadProperty<Employee>( employee, e => e.Addresses) • Can also support lazy loading with POCOs through dynamic proxies (see later)

9. Issues with POCOs – two-way relationships • Context forces EntityObject classes to be aware of two-way relationships and keeps relationships in sync • Options for doing this with POCOs: • Call DetectChanges method of context • Write code in POCO classes so that they manage their own relationships • Use dynamic proxies

10. Dynamic proxies • POCO classes can be wrapped by proxy classes which are created dynamically at runtime • Proxy class is derived from POCO class • POCO properties must be marked as virtual • Adds EF-specific behaviour which allows management of change tracking, lazy-loading and relationships in the same way as EntityObject classes • Client code works with POCO classes, but actual objects instantiated are proxies • EF uses reflection to find out about properties of POCOs and Reflection.Emit to dynamically generate IL code for proxy classes

11. POCOs and PI • POCOs do not need to derive from any persistence specific class • Do not use persistence specific collection types • Should use ICollection as collection property type • Requirement for properties to be virtual to support some capabilities through proxies • This does not violate PI – classes don’t need to know about what the derived classes will do • EF4 POCO support allows PI domain classes to be used

12. Using a repository • Rather than having client code query context directly it is common to use a repository • A repository “Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects” (Fowler) • Promotes testability • Can swap in fake context with affecting client/test code • Can program client to an interface for repository and define actual repository type through dependency injection • Allows DAL to be swapped easily • Context implements Unit of Work pattern, but often wrap this in UoW class/interface to allow further isolation of dependencies

13. IoC and Dependency Injection • Inversion of Control (IoC) • Objects do not create other objects on which they rely to do their work • Instead, they get the objects that they need from an outside source (for example, an xml configuration file) • Dependency Injection (DI) • This is done without the object intervention, usually by a container that passes constructor parameters and set properties • Castle Windsor is an example of a .NET DI container • Can manage dependencies for all kinds of service, not just persistence • http://msdn.microsoft.com/en-us/library/aa973811.aspx

14. Creating a repository • Pattern describes solution to problem, but does not strictly define how to write the code • Many variations on the Repository pattern are possible • You can design your own – there are plenty of articles and blog posts with examples to base it on • You can use a template to generate your basic implementation from an EDM • ADO.NET Unit Testable Repository Generator • Download from www.visualstudiogallery.com • EFRepository • Download from efrepository.codeplex.com

15. Model-First • All examples so far have been re-engineered from the database • Changes to the conceptual model were mapped to the original database • EF4 allows you to start by designing the conceptual model and then use that model to define the database • Model-First

16. Creating the conceptual model • Add new ADO.NET Entity Data Model item to project and select Empty Data Model in wizard • Add new Entities to model using Toolbox or right-click on designer surface • Add properties (scalar or complex) to each entity by right-clicking on entity • Set type of property in Properties window • Give each entity a key property • Add associations by right-clicking on surface or entities • Adding association creates navigation properties • Create inheritance hierarchy by specifying base class for new entities

17. Generate database • Right-click on designer surface and select Generate Database from the Model • Slightly misleading name • Database must exist – designer will generate DDL to add to database • Designer does not execute the DDL script it creates – have to do that separately • DDL Generation wizard allows you to specify the database, and creates connection string in app.config • Wizard adds SSDL and MSL portions to EDMX file and creates SQL script in project folder

18. DDL generation • Based on a T4 template • Table names come from EntitySet names • Property and association attributes set in designer will be reflected in column attributes, e.g. data types, cascade delete • Inheritance will be implemented with a TPT strategy • Many-to-many relationship implemented with a join table

19. Customising DDL generation • Possible to modify T4 template • Only template installed in VS2010 is SSDL to SQL 10.tt • Or use Entity Designer Database Generation Power Pack • Download from www.visualstudiogallery.com • Contains additional templates • Can force TPH strategy for inheritance • Provides capability to migrate existing database after making changes to model

20. Model-First and POCOs • Model-First approach is compatible with POCOs • Once EDMX has been created, you can create POCOs to mirror entities and ObjectContext class to manage them • Alternatively, the entities you create in the designer can be based on knowledge of existing POCO classes

21. Code-First • Avoid altogether working with visual model • Build your model with POCO classes • Moving towards true Domain Driven Design • Microsoft consulted with a Data Programmability Advisory Council which included Fowler, Evans and Nilsson • Currently this feature is a CTP, not included in the release of VS2010 • Need to download and install • Add reference to Microsoft.Data.Entity.Ctp.dll which is installed in Program Files\Microsoft ADO.NET Entity Framework Feature CTP5\Binaries • Add using System.Data.Entity where required

22. What does Code-First do? • You need to create POCOs and a context class which inherits from DbContext • Defines DbSet property to store a set of each entity class • At runtime it reads your class definitions and creates in-memory representation of CSDL, MSL and SSDL • Looks for connection string that has the same name as the context class • Uses convention-based persistence mapping • Convention over configuration • Creates database if it doesn’t already exist (SQL CE and SQL Express)

23. Customising mapping • Override OnModelCreating event of DbContext and use ModelBuilder class to customise mapping • Change table names • Customise column/property mapping • Split a table across multiple types • http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx • Data annotation attributes • Specify keys, string lengths, etc • http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx

24. EF4 options - summary • Database-First • Define model and mappings in EDMX • Entities are EntityObjects or POCOs • Model-First • Define model in EDMX • Entities are EntityObjects or POCOs • Code-First • Define model with POCOs • Mappings defined by convention or ModelBuilder/annotations • Entities are POCOs

25. Profiling EF • Profile at server • SQL Server Profiler • Profile at client • EF Profiler • http://efprof.com/ • Not free!