Question

I’m working on a site and there are two projects in the solution a business logic project and the website project. I understand that I want to keep the entity context out of the web project and only use the business objects the framework creates but I can’t figure out how to save a modified object this way.

Let’s say my entity model created this class:

public class Person //Person entity
{
    Int32 Id {get;set;}
    String Name {get;set;}
    Address Address {get;set;} //Address entity
}

And I created this class to get a specific person:

public static class PersonController
{
    public static Person GetById(int id)
    {
        using (Entities context = new Entities())
        {
            return context.Persons.FirstOrDefault(x => x.Id == id);
        }
    }
}

This allows me to get a person without a context by calling PersonController.GetById(1); and I can change the persons properties after I get them but I can’t figure out how to save the modified information back to the database. Ideally I would like to partial class Person and add a .Save() method which would handle creating a context adding the person to it and saving the changes. But when I tried this a while ago there were all kinds of issues with it still being attached to the old context and even if I detatch it and attatch it to a new context it gets attached as EntityState.Unchanged, if I remember right, so when I call context.SaveChages() after attaching it nothing actually gets updated.

I guess I have two questions:

1) Am I going about this in a good way/is there a better way? If I’m doing this in a really terrible way I would appreciate some psudo-code to point me in the right direction; a link to a post explaining how to go about this type of thing would work just as well.

2) Can someone provide some psudo-code for a save method? The save method would also need to handle if an address was attached or removed.

Answer 1

There are many ways to handle Entity Framework as a persistence layer.

For one, it looks like you’re not using pure POCOs. That is, you let EF generate the classes for your (in the EDMX.designer.cs file).

Nothing wrong with that, but it does inhibit a clean separation of concerns (especially when it comes to unit testing).

Have you considering implementing the Repository pattern to encapsulate your EF logic? This would be a good way to isolate the logic from your UI.

In terms of Save – this is where it gets difficult. You’re right, most people use partial classes. Generally, you would have a base class which exposes a virtual “Save” method, which the partial classes can then override.

I personally don’t like this pattern – i believe POCOs should not care about persistence, or the underlying infrastructure. Therefore I like to use pure POCOs (no code gen), Repository pattern and Unit of Work.

The Unit of Work handles the context opening/saving/closing for you.

This is how (my) Unit of Work does the magic. Consider this some code in your “Web” project:

var uOw = new UnitOfWork(); // this is class i created, implementing the UOW pattern
var person = repository.Find(10); // find's a "Person" entity (pure POCO), with id 10.
person.Name = "Scott";
uOw.Commit();

Or adding a new Person:

var uOw = new UnitOfWork();
var newPerson = new Person { Name = "Bob" };
repository.Add(newPerson);
uOw.Commit();

How nice is that? 🙂

Line 1 creates a new sql context for you.
Line 2 uses that same context to retrieve a single “Person” object, which is a hand-coded POCO (not generated by EF).
Line 3 changes the name of the Person (pure POCO setter).
Line 4 Saves the changes to the data context, and closes the context.

Now, there is a LOT more to these patterns than that, so I suggest you read up on these patterns to see if it suits you.

My repository is also implemented with Generics, so I can re-use this interface for all business entity persistence.

Also take a look at some of the other questions I have asked on Stack Overflow – and you can see how I’ve implemented these patterns.

Not sure if this is the “answer” you’re looking for, but thought I’d give you some alternative options.