Learn about the value and purpose of a data layer with or without Entity Framework.
- [Narrator] The data layer, often shortened to DAL, is an invaluable tool for a well-architected application. It is a conceptual separation from the source of the data and the business actions. With this separation, a developer can reduce the number of moving parts involved in accessing data and implementing a feature. This results in clearer, more testable, and, therefore, less buggy code. The benefits of the data layer are manyfold: inherent in the concept is a separation of the data storage and retrieval from business actions.
It also makes it simple for the business layer to reuse code, like query definitions, so that when a change to a query is required, it only needs to be done in on place. By isolating the data logic, there is less information for the developer to maintain in her head as she works. It is easier to read and understand a method, get valid products for customer, than a link query in code that does the same thing. When replacing or testing, or testing and then replacing this code, it is easy to keep to the single responsibility defined in the name.
Occasionally, one of the benefits that is espoused for a clear data layer is the idea that a data storage solution should be swapped out for something different with a minimal impact on the application. I, nor anyone I know, has ever swapped out the data solution for an application wholesale. So in practice, this argument doesn't really stand up. However, it can make sense to replace part of an existing stored solution with another one for performance or either cost reasons if using a cloud solution, like Azure or AWS.
A specific data retrieval call might be really slow within any framework but could be much more effective as a stored procedure. Isolation from the business code in this case means a lot less code to alter if the existing query was used in several places. With the cross-platform capabilities inherent in .NET core, it is possible to share business logic for native mobile, web, desktop and server applications. Rarely would all the code be shared, but sharing specific pieces of logic related to something like validating an order can be very useful.
These applications can use different data storage solutions against the same business layer. A mobile application can use SQLite to act against data cached locally while the server and web applications can act directly against the data layer in SQL server. The downfall of all this sharing is, of course, the applications become coupled through the shared code. If a change needs to be made in the logic, both applications need to be redeployed together. Web deployment might be very simple, but deploying a mobile app can take several days.
These issues can be mitigated with application code, but they need to be considered when making this architectural decision. The data layer provides a significant step in testability, not just for the data layer, but the business layer. It is a lot simpler to write a test against a query separate from the logic that is being executed against the results of the query. It also means that it is possible to write and verify through testing a business layer method without having written the data layer piece yet.
The data layer and business layer communicate through interfaces rather than concrete classes. Interfaces are not just extra code to add when there is a new method in a class. Besides being something to test or inject an implementation against, they help one logically consider what a layer or a module of code is responsible for. A monolithic interface with a lot of different functionality can be a good indicator of bad code that is going to be buggy and hard to maintain. Favor small, more granular interfaces to keep functionality isolated.
This allows flexibility in testing and refactoring. Don't be afraid to implement several small related interfaces in a single class if they belong together logically. Entity Framework itself simplifies the data layer substantially. But in most real world applications, it still makes sense to have a data layer. Don't pigeon hole the data layer to just database access. It can be used for any kind of resource for storage. Thinking about it this way helps keep a mental separation when coding the layers of an application.
One of the most popular patterns to use within the data layer is the repository pattern. In the next video, I'll discuss the benefits and drawbacks of this pattern and how it fits into the data layer with some examples in our demo application.
- What is good application architecture?
- Real-world software and the SDLC
- Common knowledge and maintenance
- Choosing an architecture
- Design patterns with EF
- Debugging and error handling
- Architecture for the web with ASP.NET
- Designing for unit testing
- Strategies for dealing with common performance issues