Lazy Loading, DAL and BLL abstraction

Question

I'm asking myself a question to code the right way on a new fresh project.

I have a designed database and I mapped tables to equivalent POCO classes using Entity Framework 6 Code First.

Then, I thought "wait, if some day I want to switch from EF to another Framework for whatever reasons, or even say let's go for direct coding because of performance reasons, I must NOT use EF directly in the BLL. So, EF is NOT a DAL.

I started implementing a DAL that encapsulates EF calls. Then, I implemented a BLL consoming the DAL. For some tables this is like a direct mapping because these are "parameters tables" (countries, currencies and so on). But for others there is a good part of business logic, which is fine.

BUT

Then it comes to Lazy Loading, attaching entities etc.

Let's talk only about Lazy Loading.

1) Use Lazy Loading : when I'm so far in the BLL, I don't know any more about the underlying DAL internals. I just consume my objects, and I think "hey, every property will come just when I need it". But OMG! I'm outside the DAL, the Datacontext is not there anymore, so nothing can load anymore. Should I keep the EF data context open for the whole life of the application ? I've read it's not a good practice, even more when it comes to a eBusiness website keeping alive forever...

2) Don't use Lazy Loading but eager loading. Right, I load all the properties of my object, so every data is available for my consuming BLL. Ahem, do I really need, when loading a customer, to load all his orders, comments, addresses, countries and properties of the countries, currencies etc.etc.etc... This seems really overkill and can't live in a web application...

But, the DAL should NOT know about what the BLL needs. The DAL is here to provide data access, then the BLL will do what it needs to load just what it needs. So should I provide DAL methods to include/not include any combination possible of foreignkeys ? Seems not possible ... Should I wait for the BLL developper to tell me what methods he needs for each of his requirements? Seems too much coupled... Should the BLL be able to tell the DAL exactly what it needs? How to do that without being too much coupled?

Seems like Lazy Loading is not applicable in a multi-layer application...

Answer 1

wait, if some day I want to switch from EF to another Framework for whatever reasons

No, you wont.

There are two reasons why what you are doing is bad idea. First. Changing ORM is extremely rare and building all your abstractions around something like that is not a good idea. Abstractions should first and foremost be build around things that change often, so you can add those changes without having to change the code. And in data-access layer, things that change most often are the entities, how you query those entities and how you persist them. Compare that to the extra slim possibility of completely replacing your data access layer and you are going to spend changing lots of code for things that really matter and just adding code for things that don't matter. Which is opposite to how it is supposed to be.

Second is the fact that ORMs, and data access in general are complex. Sometimes even more complex than applications that use them. Also, there are huge differences between them. Even thought they might seem same, the details make them behave differently at many corner cases. Trying to build abstractions around things so complex will inevitably result in both non-abstracting and leaky abstractions. So even if you are going to change persistence framework, you will have to change many things in business layer or implement behavior so it is same as previous framework. This is actually what you are encountering. You are trying to abstract something that is too complex to be properly abstracted away without reimplementing the whole thing.

I would highly recommend you rethinking your design without the "can't use EF directly" mentality.