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

Product type Paperback

Published in Mar 2022

Publisher Packt

ISBN-13 9781803249841

Length 678 pages

Edition 2nd Edition

Languages

Tools

.NET

Concepts

Design Patterns

Author (1):

Carl-Hugo Marcotte

View More author details

Table of Contents (31) Chapters

Preface

1. Section 1: Principles and Methodologies

2. Introduction FREE CHAPTER

3. Automated Testing

4. Architectural Principles

5. Section 2: Designing for ASP.NET Core

6. The MVC Pattern Using Razor

7. The MVC Pattern for Web APIs

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

9. Deep Dive into Dependency Injection

10. Options and Logging Patterns

11. Section 3: Designing at Component Scale

12. Structural Patterns

13. Behavioral Patterns

14. Understanding the Operation Result Design Pattern

15. Section 4: Designing at Application Scale

16. Understanding Layering

17. Getting Started with Object Mappers

18. Mediator and CQRS Design Patterns

19. Getting Started with Vertical Slice Architecture

20. Introduction to Microservices Architecture

21. Section 5: Designing the Client Side

22. ASP.NET Core User Interfaces

23. A Brief Look into Blazor

24. Assessment Answers

25. Acronyms Lexicon

26. Other Books You May Enjoy

27. Index

Appendices

1. Appendix A

2. Appendix B

Abstract layers

This section looks at abstract layers with an abstract data layer implementation. This type of abstraction can be very useful and is another step closer to Clean Architecture. Moreover, you can abstract pretty much anything this way, which is nothing more than applying the Dependency Inversion Principle (DIP).

Let’s start with the problem: the domain layer is where the logic lies, and the UI links 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 directly depends on it.

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