2

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

Community
  • 1
  • 1
Davide
  • 1,305
  • 3
  • 16
  • 36

2 Answers2

3

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.

MVC 4 Architecture

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.

Kevin Junghans
  • 17,475
  • 4
  • 45
  • 62
  • Lot stuff to be read .. that's cool :) I definitly need to improve my acrhitecture skills (now I'm a newbie very very newbie!!) – Davide Jan 24 '13 at 14:37
  • This is a good architecture if you're doing very low level data access (raw ADO.NET commands for example). However I would argue that Entity Framework **is** your repository and UOW. The dbcontext is designed to fill both of those roles, so I would not add extra unnecessary layers on top of that. – MattDavey May 08 '13 at 15:39
  • MattDavey - I totally disagree with your comment. If you look at the links I provided in my answer for the Repository and UOW Design Patterns you will see detailed descriptions of how to implement them when using EF. And by using these design patterns you can easily mock the EF layer for unit testing or swap out EF for another ORM without impacting the application layer. There are definite benefits to adding these layers to EF and not use EF directly from your application or domain layer. You do not have to use them but you are making your application more brittle by doing so. – Kevin Junghans May 08 '13 at 17:49
  • Being able to "swap" ORMS is the same old justification that people have been using for years - but realistically how often does that happen? Almost never. I agree on the point of unit testing, but in that case lets call it what it is - a testing seam - not disguise it as an architectural layer. If you're re-implementing two major things that Entity Framework is designed to solve, what's the point even using Entity Framework? Might as well use something like Dapper, which has no notion of repositories or UOW. – MattDavey May 09 '13 at 08:11
  • See this post for a detailed explanation of why repositories are often unnecessary complexity when you're using a rich ORM such as EF or NHibernate > http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer – MattDavey May 09 '13 at 08:18
  • MattDavey - You mentioned in an earlier comment that it is a good architecture for low level data access. Well some times I have to do that because the ORM is not efficient for certain types of queries. Then it is encapsulated in the Repository. I will concede it is not a one size fits all architecture, but for large enterprise applications I have seen the benefits first hand and would not do it any other way. I prefer to architect my applications to be flexible because if the software is of any use and is around for a while you never know what changes are coming. – Kevin Junghans May 09 '13 at 13:33
  • MattDavey - I read the referenced blog and not everyone in the comments agrees with the author either. – Kevin Junghans May 09 '13 at 13:34
1

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
Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
  • Thanks. Do I assume correctly that View Models should be in BL? And, apart validation and special cases, a lot of view models are entities that are the same I have in DAL .. so I need to create two classes that uses the same interface, or I'm wrong? – Davide Jan 24 '13 at 13:48
  • 1
    View Models in the BL yeah, ones based on entities should implement the same interface the entity does, to allow for easier transition between types/interface. You are right :) – Mathew Thompson Jan 24 '13 at 13:53