large_default.png

medium_default.png

small_default.png

thumbnail_default.png

default.png

Jeremy Castillo

favicon.png

thumbnail_27326587.png

27326587.png

# Stress Free Data Management
Implementing a Data Access Layer (DAL) within your application can eliminate pointless hours of debugging and prevent repeated code. This layer of abstraction is one of the first software architecture practices you want to adopt in any new data reliant project. Here are 3 reasons why building your application on top of a Data Access Layer from the start will help ensure your project's success. 

## 1. Abstraction
The last thing you need when developing a new project, is to remember the specific SQL query syntax for your database each time you need to load data. Creating an abstracted Data Access Layer with standardized CRUD operations removes the mental load of data retrieval when you want to be focusing on business logic.  One style of implementing this layer is with extension methods. 

```csharp
using System.Threading.Tasks;

public static class EfCoreReadExtensions
{
    public static async Task<TModel> ReadAsync<TModel>(this DbSet<TModel> dbSet, Expression<Func<TModel, bool>> predicate)
        where TModel : class
    {
        // You can do a lot of other fun stuff here! 
    
        return await dbSet.FirstOrDefaultAsync(predicate);
    }
}
```
Then you can call `dbContext.Users.Read(u => u.Name == userName)` in your business logic. Adding a caching layer within the extension adds a lot of functionality for little effort, since you won't have to change any of the said business logic. 
## 2. Testability
Extracting data access into its own layer lets you test code independently, and allows you to easily mock data. 
```
    [Fact]
    public void Read_ReturnsMatchingUser()
    {
        // Arrange
        var users = new List<User>
        {
            new User { ID = 1, Name = "Alice", Email = "alice@email.com" },
            new User { ID = 2, Name = "Bob", Email = "bob@email.com" }
        }.AsQueryable();

        var mockSet = new Mock<DbSet<User>>();
        mockSet.As<IQueryable<User>>().Setup(m => m.Provider).Returns(users.Provider);
        mockSet.As<IQueryable<User>>().Setup(m => m.Expression).Returns(users.Expression);
        mockSet.As<IQueryable<User>>().Setup(m => m.ElementType).Returns(users.ElementType);
        mockSet.As<IQueryable<User>>().Setup(m => m.GetEnumerator()).Returns(users.GetEnumerator());

        // Act
        var result = mockSet.Object.Read(u => u.Name == "Alice");

        // Assert
        Assert.NotNull(result);
        Assert.Equal("Alice", result.Name);
        Assert.Equal("alice@email.com", result.Email);
    }
```
## 3. Flexibility 
User requirements are constantly changing, database technologies go in and out of style, and we don't want any of those things to lead to a massive refactor of the application. Whether you want to swap MySQL for Postgres, add your own data validation middleware, or change your caching method, you would be stuck rewriting the majority of your application if your data access methods are not contained in their own layer. 

A Data Access Layer is a worthwhile component to add to nearly any level of software application. Remove the danger and tedium of database communication with this technique. 

Photo by panumas nikhomkhai: https://www.pexels.com/photo/close-up-photo-of-mining-rig-1148820/

Top 3 Benefits of a Data Access Layer