You're reading from An Atypical ASP.NET Core 5 Design Patterns Guide A SOLID adventure into architectural principles, design patterns, .NET 5, and C#

Product type Paperback

Published in Dec 2020

Publisher Packt

ISBN-13 9781789346091

Length 762 pages

Edition 1st Edition

Languages

Tools

.NET

Concepts

Design Patterns

Author (1):

Carl-Hugo Marcotte

View More author details

Table of Contents (27) Chapters

Preface

1. Section 1: Principles and Methodologies

2. Chapter 1: Introduction to .NET FREE CHAPTER

3. Chapter 2: Testing Your ASP.NET Core Application

4. Chapter 3: Architectural Principles

5. Section 2: Designing for ASP.NET Core

6. Chapter 4: The MVC Pattern using Razor

7. Chapter 5: The MVC Pattern for Web APIs

8. Chapter 6: Understanding the Strategy, Abstract Factory, and Singleton Design Patterns

9. Chapter 7: Deep Dive into Dependency Injection

10. Chapter 8: Options and Logging Patterns

11. Section 3: Designing at Component Scale

12. Chapter 9: Structural Patterns

13. Chapter 10: Behavioral Patterns

14. Chapter 11: Understanding the Operation Result Design Pattern

15. Section 4: Designing at Application Scale

16. Chapter 12: Understanding Layering

17. Chapter 13: Getting Started with Object Mappers

18. Chapter 14: Mediator and CQRS Design Patterns

19. Chapter 15: Getting Started with Vertical Slice Architecture

20. Chapter 16: Introduction to Microservices Architecture

21. Section 5: Designing the Client Side

22. Chapter 17: ASP.NET Core User Interfaces

23. Chapter 18: A Brief Look into Blazor

24. Assessment Answers

25. Acronyms Lexicon

26. Other Books You May Enjoy

Leave a review - let other readers know what you think

Abstract data layer

In this section, we will be implementing an abstract data layer to explore repository interfaces. This type of abstraction can be very useful and is another step closer to the Clean Architecture.

Let's start with the problem: the domain layer is where the logic lies, and the UI is the link between the user and the domain, exposing the features built into that domain. On the other hand, the data layer should be an implementation detail that the domain blindly uses. The data layer contains the code that knows where the data is stored, which should be irrelevant to the domain, but the domain indirectly depends on it.

The solution is to break the tight coupling between the domain and the data persistence implementations by creating an additional layer that is abstract, as shown in the following diagram: