views:

48

answers:

1

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.

+1  A: 

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

For one, it looks like your not using pure POCO's. 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 seperation 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 POCO's should not care about persistence, or the underlying infrastructure. Therefore i like to use pure POCO's (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 StackOverflow - and you can see how i've implemented these patterns.

Not sure if this is the "answer" your looking for, but thought i'd give you some alternative options.

Hope this helps.

RPM1984
I'm a pretty new developer so I don't have a lot of experience with design patterns yet. Thus I don't really know how to use the repository pattern but I can look that up. Why would you not want to use the EF generated objects though? I thought the whole point of EF was that it auto generates the objects and that is supposed to save you time coding; both in that you just don't have to code as much and in that you don't have do test the code your not writing.
William
Well there are a plethora of reasons, too many to go into here. The main one is scalability. If you let EF generate your classes, those classes are 'tied' to EF, and are database aware. They need to know how they're being used (mapping). With POCO's, they have no idea. Therefore you could switch out EF for nHibernate (for example) with no extra code changes. Plus your classes now purely represent your domain model - they are not cluttered with navigational properties and event delegates. For simple apps though (ones that wont be long lived), EF gen is fine.
RPM1984
RE testing - you don't directly test the classes, but for example if you had a service layer (most apps do), you need to ensure you can create/retrieve/delete entities. By using code-gen, you'll need a reference to entity framework when testing the service layer. THis shouldn't be required. What you end up with is ALL projects referencing Entity Framework - therefore you forfeit the 'loose coupling'.
RPM1984
Ok so I would like to try implementing a setup like yours but I'm new and I don't really know anything about the repository pattern. I pick up quick though if I have an example. Is there a tutorial you can point me to that will get me started?
William
Sure buddy, this is the (brilliant) article i used to get my solution going: http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/. It covers EF w/ POCO's, Repository, and Specification pattern, all in .NET. Hope it helps.
RPM1984
There is no real 'tutorials' on it, as its not a skill, it's a design pattern. That is why the best way to learn is reading/trying things out.
RPM1984
Thank you. I'll definitely give that a read through. Much appreciated.
William
No worries. It's good to get a grasp of these things early. As i said, you dont HAVE to use POCO's, Repository pattern, etc. You can use EF code-gen. But what i have found is while this works in smaller, short-life applications, maintanability becomes a factor for longer applications (as i found with our previous project, hence we are rewriting from scratch).
RPM1984