views:

65

answers:

2

What pattern should I use for data-access in case of VS2008 generated L2s or EF DataModels? Repository-pattern or what?

As we know VS2008 generates Data-Models and DataContexts/ObjectContexts in the same file, then, how should I arrange my VS2008 assemblies in my VS2008 solution to achieve a layered design?

If I use repository pattern, how should I arrange my assemblies in the VS2008 solution (as Data-Models and Data/Object-Contexts are stored in the same file...)?

Any web/example link would be appreciated.

+1  A: 

In my Entity Framework project, I've kept all the auto generated code as it is, and extended some of the auto generated partial classes for more specific functionality (I sometimes convert the object of the auto generated classes to my project classes).

I think the model and some of your extensions to it should be in one assembly. You can have different classes that will hold the data in a different way - and they should be in a different assembly that the DataModel assembly will reference.

Perhaps I don't see the question right. If you want, try and further explain what you're trying to achieve.

brickner
If I want to separate my C# assemblies into 3-layers (DataAccess, POCO and UI, or however you like it), Entity Framework's auto generated models do not come with much help. Coz, models and data-access codes reside in the same place. What is your answer then? If you know NHibernare, you can understand that, NHibernate strongly supports repository pattern and through which it is very easy to separate an application into 3 layers. If case of EF's auto-generated code, I can find no clear cut way to use Repository pattern. Or you can suggest me any other DA pattern for EF, if you like.
JMSA
You can treat Entity Framework's auto generated as the DataAccess, write a different assembly that will contain the POCO part and a different assembly for UI.You don't have to treat the auto generated classes as your POCO. Remember that they usually won't fit exactly like what you need for your program since they are too automatic.
brickner
+1  A: 

What I've done is to wrap (in my case Linq2Sql) in my own custom class, which implements the repository pattern, here's the pasted excerpt from a previous but somewhat related answer.

I'd recommend reading through The Onion Architecture and looking at the MVC StoreFront videos for inspiration. The magic part is, pushing the Linq2Sql part or EF stuff to one side, So you don't sit on top of it as much as, Pull it in if you want it, that way you could use Linq2Sql or EF or NHibernate. This is more work, but gives you more flexibility.

Here's my example CarProject

In Car.Core project

 public interface ICarRepository
 {
    IQueryable<Car> GetAllCars();
    void Add(Car);
 }

I then have a implementation of the interface which wraps up access to the generated Linq2Sql class.

Car.Data project

public class SqlCarRepository : ICarRepository
{
    private CarDataContext _context;

    public SqlCarRepository()
    {
        _context = new CarDataContext();
    }

    #region ICarRepository Members

    public IQueryable<Car> GetAllCars()
    {
        return _context.Cars;
    }

You could have a EF equivilent ofcourse, or NHibernate.

I haven't got all this completely sorted, and I'm still learning but I currently have these projects:

Car.Core         --- All the interfaces and domain objects, DTO's etc
Car.Core.Tests   --- The tests of the core business logic.
Car.Web          --- Asp.net MVC frontend
Car.Web.Tests    --- Tests for the website
Car.Data         --- The Linq2Sql stuff lives in here
Car.Data.Tests   --- The tests for the DAL layer

In your scenario you could either put EF in Car.Data or maybe change it to Car.Linq2Sql and Car.EntityFramework. Not sure what I'd do.

danswain