Building Next Generation Data Access Layers with the ADO.NET Entity Framework (Repeated from 6/3)
Play Building Next Generation Data Access Layers with the ADO.NET Entity Framework (Repeated from 6/3)
As developers, we've been building components in our data access layer (DAL) with ADO.NET classes such as Connections, Commands, DataReaders, DataSets and our own custom Helper classes and Data Classes. We build data access layers with a clear separation of concerns between business logic, data access, and data storage. We do this to increase cohesion and maintainability of our code, and also to increase developer productivity. What does this exactly mean in terms of the Entity Framework? What is the best approach to using the Entity Framework within our Data Access Layer? There are several workable models for leveraging the Entity Definition Model (EDM) within our applications. On one end of the spectrum, we can use the Entity Definition Model as a tactical tool for data access which is isolated to our Data Access Layer. This hides the Entity Framework from the rest of our application, effectively separating the concern of data access from the rest of our application. Another technique includes leveraging the conceptual Entity Definition Model deeply throughout our solution's layers and tiers. In this session, we compare and contrast these approaches including the middle ground, and see how these architectural choices affect maintainability, readability, and developer productivity. Most developers don't frequently have the opportunity to start from a fresh slate, so we also examine a refactored evolution from traditional data access layers through to incremental use of the Entity Definition Model.