When it comes to the development of database independent with an easily maintainable Data Access Layer(DAL), the best solution that comes to my mind is the Entity Framework by Microsoft. Moreover, when you are short of time and need development at a Rapid pace and less code, Entity Framework is a winner. Initially, some of us in the developer community did not receive the concept well and were reluctant to use it in the solutions. However, slowly but surely people have started realizing the fact that, Entity framework can be a great tool for quick development of a DAL as long as the developer is aware about its limitations and what is going on under the hood. Most of the problems have their root cause in the way developers implement their solutions around Entity Framework (EF).
A few misconceptions or misinterpretations on the developer’s part can lead to serious problems going ahead. Here are a few guidelines that in my opinion should be kept in mind while implementing EF in a project.
Abstraction
Entity Framework provides developers with an abstraction which helps them to write the data access layer code quickly and easily.
This is a great feature till the time the developer does not forget about the database due to this abstraction. It is a grave mistake to think that there is no need to worry about what is happening at the DB level. This ignorance can give rise to major bottlenecks when the system actually goes live.
Using EF in your DAL does not mean that there is no need for tuning the database or replacing the non performing LINQ queries with custom stored procedures.
Where to use?
Entity Framework was designed and developed for making it really simple to write CRUD operations and retrieval scenarios in the DAL code. However, many developers are dissatisfied with its performance when it comes to bulk operations for which it was never designed.
It is always the best bet to use right tools for the right Job.
Data Fetching
Most developers do not think of optimal data fetching, as they feel that there is a framework managing things for them and so optimal resources would be consumed. This is a misconception. The framework only gives you easy ways of writing code, the efficiency still depend on how you write your code.
Inefficient data fetching techniques would surely land you in trouble when it comes to performance. EF gives you an option while loading an Entity, whether to load any related Entities at the same time. Ideally only the required data should be loaded.
Managing Contexts
Entity Framework depends on the Data Context object for providing data access. Bad management of these objects is a common source of many problems. These contexts allow tracking changes to the entities and thus people are tempted to keep them open longer than they are actually required.
One approach is to use a context for a single operation and drop it as soon as the operation completes. However, if proper control mechanisms are not employed then there are high chances of developing concurrency problems as the contexts would start to clash.
The real problem starts when the context is kept alive between service calls in a client-server solution. Managing context between service calls is a very complex task and may lead to serious scalability issues as you pull a new set of resources to service each client.
In such a scenario, a complete stateless approach is best suited as it is easy on the resources and requires a far less complex solution. Any information that needs to be persisted between service calls should be persisted on client side instead of creating a bonding between contexts and sessions. There can be other approaches which dictate the lifetime of a context and which may suit better for a particular scenario or project. The bottom line is, contexts should be managed in an efficient way for getting the most out of EF.
So to conclude, my recommendation is, it is always a wise decision to follow “Horses for Courses” strategy. EF may not be best suited for scenarios like bulk updates, but it can be effectively put to work where you need a DAL for CRUD operations and to simplify the retrieval scenarios. We have used entity framework in one of our RESTful Services which is consumed by a mobile application. Entity framework is indeed a powerful productivity tool that brings in reduction in development time and simplified maintenance.
