MVC4 + EntityFramework architecture

Question

Following the desing proposed here MVC3 and Entity Framework , I'm trying to create different layers for DAL, BL and web, using MVC4 + EntitiFramework5.

Quote from @Davide Piras

1 - ProjectName.Interfaces (Class library, entities's interfaces);

2 - ProjectName.DAL (Class library, the only one allowed to even know the EF is used, the POCO entities implement the interfaces of project 1 using another file where you redeclare same objects using partial classes...);

3 - ProjectName.BL (Class library, Business logic, references the two projects above 1 and 2);

4 - ProjectName.Web (ASP.NET MVC application, Presentation Layer, references two projects 1 and 3 but NOT 2);

I have a doubt on the connection between BL and DAL. DAL knows EF, BL shoudln't .. but how to implement it? I mean, I created the classes that represent my entitis on both the layers (and this seems a bit a duplication to me .. even if in BL I'll add validation and other sutff), but how I expose the database values to BL?

in the default MVC4 solution I have

 DbSet<Entity> entity

that I can query (.Find, etc) .. I suppose I need to map them in my BL (IQueryable? IEnumerable? Isomething??)

compltely confused .. any helps is appreciate

Answer 1

The lines can become a little blurred when you speak of DAL and EF. In some cases you could consider EF the DAL . But I usually do not have the the BL access EF directly and abstract it to a higher level, so that you could easily swap out EF as your ORM if need be. I use the Repository Design Pattern to further abstract EF. The other advantage to this pattern is that it makes it easier to unit test and you can use dependency injection. I also use the Unit of Work Design Pattern to handle transactions in the system. So are the Repository and the Unit of Work part of the DAL or is it just EF. That is probably debatable and I know longer concern myself with trying to define the DAL. Here are the layers I would recommend using in an MVC 4 project.

The Application or Domain Layer is your BL Layer. I tend to incorporate concepts used in the Service Layer in this layer as I have not seen any benefit yet in separating it out. But there is the option of adding this layer on the top also.

Answer 2

No, the Business Logic layer needs to know about the DAL because it needs to call methods on the DAL in order to retrieve/update/add data ( only using the Interfaces, it shouldn't be allowed to see the POCO classes ). The BL doesn't know anything about EF (which is as it should be, incase you ever wanted to replace EF with something else).

So, for example to add a new record:

• User adds the new details and submits the form

• Web project calls AddItems in the BL layer (using a list of objects that are the interface )

• BL project has some business logic, additional validation before passing the list of objects to the DAL (also has the error handling too maybe)

• DAL creates the items in the database, then, if required, passes a list of the interface back