Entity Framework

Introduction

The entity framework is Microsoft’s offering into the ORM market. Subsequently it maps databases to entities or objects with zero coding. Wikipedia has the following to say here.

Version 1.0 has been released as part of VS.NET 2008 Service Pack 1 and the MSDN pages start here

Although there has been some controversy about the tool, however Microsoft are determined that the Entity Framework is the ORM they are going to continue to develop (as opposed to LinqtoSQL), subsequently there are a lot of enhancements in VS.NET 2010.

There are a lot of guides to how to use the Entity Framework, however there where a number of pain points I came across, and a difference of behaviour depending on whether the object became “detached” or not. This blog discusses these, some of the code is mine some of it is not ;-) Also there is some usage of new features which I hope to reference as we go along.

The code is based on a real world example and subsequently it works! but also the entities in the examples jump around quite a bit, for which I apologise.

Creating the mappings.

Actually creating the mappings to the Database is a simple task, and there is a video here. however it is simply a case of create a new ADO.NET Entity Data Model from the Add Items dialog in Visual Studio.NET 2008. Then navigate the wizard to point it at the database, select the items you want to model and the model will be generated.

If you later need to refresh the model you can do so by right clicking and choosing “update model from the Database.”

It is also advised to change the names of the Entities for example pluralise etc.

You will notice that the Foreign Keys have been converted to “Navigation Properties” . These are quite clever for each navigation property there are 2 properties, one is the Object, and the other is a reference to the object.

Populating Objects

When you import the entities, you generate a class inherited from System.Data.Objects.ObjectContext, this is your object context (almost an equivalent to DataContext in LinqtoSQL). In the examples I am using this is called TimesheetsEntities.

My first lesson or Oh That is Why (pt 1).

So the first pain point I came across, was the time it takes to create and destroy the ObjectContext. Which frustrated me as the examples often showed all of the database work happening inside a Using statement.

To prevent this, I created a Static Property for the ObjectContext so I could reference it without constantly creating and destroying it. Something like below

Code Snippet

1. private static TimesheetsEntities _timesheetsEntities;
2. public static TimesheetsEntities timesheetsEntities
3. {
4. get
5. {
6. if (_timesheetsEntities == null)
7. {
8. _timesheetsEntities = new TimesheetsEntities();
9. }
10. return _timesheetsEntities;
11. }
12. set { _timesheetsEntities = value; }
13. \

Getting Data.

Populating the objects is relatively simple, the code below returns a Generic list of all of the Users.

Code Snippet

1. public List<User> GetUsers()
2. {
3. return timesheetsEntities.Users.ToList<User>();
4. \

However if we want to do something a little more funky we can incorporate some Linq, for example an Order by

Code Snippet

1. public List<Status> GetStatuses()
2. {
3. 
   
4. var statuses =
5. from n in timesheetsEntities.Statuses
6. orderby n.OrderBy
7. select n;
8. 
   
9. return (statuses.ToList<Status>());
10. \

or if you want to get an item based on a key, again I simple piece of linq this time using a Lambda expression.

Code Snippet

1. public Status GetStatus(int StatusId)
2. {
3. return timesheetsEntities.Statuses.FirstOrDefault(m => m.StatusId == StatusId);
4. }
5. 
   

Saving Data

This is where the fun starts, and the degree of fun depends on whether the entity is attached to the Object Context or not also whether it is an insert or not.

Inserts

These are easy, as the entity is new it is always unattached.

In the case below I have my context (timesheetsEntities from above) and I want to add my “project” entity so I call the AddToProjects method. An AddTo… method is created for all of the entities you mapped above.

The save routine is clever and if you have an Object Graph, an Object with Child Objects the whole graph is saved. An example would be Invoice with Lines.

Code Snippet

1. timesheetsEntities.AddToProjects(project);

Updates (attached)

This is a little more complicated. So the object context can determine if and what needs changing you need to get a copy of the current object. Once you have done this you can apply the changes to the Object Context, using the ApplyPropertyChanges method.

Code Snippet

1. object pObject;
2. if (timesheetsEntities.TryGetObjectByKey(project.EntityKey, out pObject))
3. {
4. timesheetsEntities.ApplyPropertyChanges(project.EntityKey.EntitySetName, project);
5. \

At the end of this you need to tell the entity frame work to save.

all in all it looks a little like this

Code Snippet

1. //TODO: this is insert what about update?
2. if (project.ProjectId == 0)
3. {
4. timesheetsEntities.AddToProjects(project);
5. }
6. else
7. {
8. 
   
9. object pObject;
10. if (timesheetsEntities.TryGetObjectByKey(project.EntityKey, out pObject))
11. {
12. timesheetsEntities.ApplyPropertyChanges(project.EntityKey.EntitySetName, project);
13. }
14. 
    
15. 
    
16. }
17. 
    
18. int changes = timesheetsEntities.SaveChanges();
19. 
    

Updates Detached (Or Oh that is how pt2 – Oh well I lost count)

It as at this point the Entity framework starts getting inconsistent, and I nearly lost a lot of hair.

You can identify if the entity is attached or not by testing it’s entityState property.

Code Snippet

1. if (timeSheet.EntityState == EntityState.Detached)
2. 
   

The first inconsistency is ApplyPropertyChanges no longer save foreign key constraints. So for example the timesheets entity (above) has a Status (which is a lookup table). If this changes in the Attached model this seems fine, however when you are Detached it is not.

However i found this on the internet, which explains creating an extension method which will update the object for all of the items.

This extension method needs to be placed in a separate static class.

Code Snippet

1. public static void ApplyReferencePropertyChanges(this ObjectContext context, IEntityWithRelationships newEntity, IEntityWithRelationships oldEntity)
2. {
3. foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())
4. {
5. var oldReference = relatedEnd as EntityReference;
6. 
   
7. if (oldReference != null)
8. {
9. var newReference = newEntity.RelationshipManager.GetRelatedEnd(oldReference.RelationshipName,
10. oldReference.TargetRoleName) as EntityReference;
11. 
    
12. if (newReference != null)
13. {
14. oldReference.EntityKey = newReference.EntityKey;
15. }
16. }
17. }
18. \

The second inconsistency is the object graph is not saved. So you need to iterate through each of the child objects and save them individually. This is a bit long winded and I have a lovely selection of error messages that went with it.

So in my Model the Timesheet has lines. As in an update these might have changed, the first stage is, to loop through each of the items and call a save routine. Which sounds straight forward. Except some are new, so we have to differentiate in our save routine.

The next problem I had was “The object cannot be added to the ObjectStateManager because it already has an EntityKey. Use ObjectContext.Attach to attach an object that has an existing key”

The cause of this error was because the Navigation Properties where confusing the Object Context, so for each of the navigation properties I had to remove the Objects and set the EntityKey to the Reference of the Navigation Property.

Code Snippet

1. if (timeSheetLine.TimeSheetLineId == 0)
2. {
3. TimeSheetLine newTimeSheetLine = timeSheetLine.Clone<TimeSheetLine>();
4. 
   
5. newTimeSheetLine.TimeSheets = null;
6. newTimeSheetLine.TimeSheetsReference = null;
7. newTimeSheetLine.TimeSheetsReference = new EntityReference<TimeSheet>();
8. newTimeSheetLine.TimeSheetsReference.EntityKey = timeSheetLine.TimeSheets.EntityKey;
9. 
   
10. 
    
11. newTimeSheetLine.Projects = null;
12. newTimeSheetLine.ProjectsReference = null;
13. newTimeSheetLine.ProjectsReference = new EntityReference<Project>();
14. newTimeSheetLine.ProjectsReference.EntityKey = timeSheetLine.ProjectsReference.EntityKey;
15. 
    
16. timesheetsEntities.AddToTimeSheetLines(newTimeSheetLine);
17. }
18. else
19. {
20. 
    
21. object pObject;
22. timesheetsEntities.TryGetObjectByKey(timeSheetLine.EntityKey, out pObject);
23. timesheetsEntities.ApplyPropertyChanges(timeSheetLine.EntityKey.EntitySetName, timeSheetLine);
24. 
    
25. timesheetsEntities.ApplyReferencePropertyChanges(timeSheetLine as IEntityWithRelationships, pObject as IEntityWithRelationships);
26. 
    
27. 
    
28. }
29. 
    

The astute of you will notice the Clone method which is not a method of ArrayList again this is another Extension method. Again I found it on the internet but I am afraid I have lost the reference. The object needed to cloned because you cannot change an object in a foreach, but also this created some reasonably elegant code.

Code Snippet

1. public static T Clone<T>(this T source)
2. {
3. var dcs = new System.Runtime.Serialization
4. .DataContractSerializer(typeof(T));
5. using (var ms = new System.IO.MemoryStream())
6. {
7. dcs.WriteObject(ms, source);
8. ms.Seek(0, System.IO.SeekOrigin.Begin);
9. return (T)dcs.ReadObject(ms);
10. }
11. }
12. \

Conclusion

Although the Entity Framework does cause some headaches, I think it is a good technology with lots of potential. Hopefully this helps solve some of the problems, I have some ideas on how to deal with dirty reads and writes which I will post later.