Does Entity Framework Void the Need for a Separate Data Access Layer?

Architecturedata structuresentity-frameworkseparation-of-concerns

The way it was

For years, I have organized my software solutions as such:

  • Data Access Layer (DAL) to abstract the business of accessing data
  • Business Logic Layer (BLL) to apply business rules to data sets, handle authentication, etc.
  • Utilities (Util) which is just a library of common utility methods I have built over time.
  • Presentation Layer which could of course be web, desktop, mobile, whatever.

The way it is now

For the past four years or so I have been using Microsoft's Entity Framework (I am predominately a .NET dev) and I am finding that having the DAL is becoming more cumbersome than clean on account of the fact that the Entity Framework has already done the job that my DAL used to do: it abstracts the business of running CRUDs against a database.

So, I typically end up with a DAL that has a collection of methods like this one:

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

Then, in the BLL, this method is used as such:

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

This is a simple example of course as the BLL would typically have several more lines of logic applied, but it just seems a bit excessive to maintain a DAL for such a limited scope.

Wouldn't it be better to just abandon the DAL and simply write my BLL methods as such:

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

I am considering dropping the DAL from future projects for the reasons stated above but, before doing so, I wanted to poll the community here for your hindsight/foresight/opinions before I get down the road on a project and discover a problem I didn't anticipate.

Any thoughts are appreciated.

Update

The consensus seems to be that a separate DAL isn't necessary but (making my own inference here) is a good idea to avoid vendor lock in. For example, if I have a DAL that is abstracting EF calls as illustrated above, if I ever switch to some other vendor I don't need to rewrite my BLL. Only those basic queries in the DAL would need to be rewritten. Having said that, I am finding it tough to envision a scenario in which this would happen. I can already make an EF model of an Oracle db, MSSQL is a given, I am pretty sure that MySql is possible as well (??) so I am not sure if the extra code would ever grant a worthwhile ROI.

Best Answer

Not sure if this is the answer you're looking for.. but here goes.

We do it to keep things separated/organised. Yes, EF/NHibernate are data access.. but we limit its use to its own assembly with a generic repository setup. This assembly also contains all of our NHibernate mappings, Session factory, code for handling multiple databases, etc.

We still refer to it as the "Data Access Layer", because the entire assembly exists to support our ORM.

I should probably note that our main app references 5 databases, has roughly 4-500 domain objects/mappings and various schemas. So, this setup makes sense for us. Perhaps for a smaller app you would skip this assembly but.. I am a sucker for organised code and would probably do it anyway :)

Related Topic