Clean Architecture: Understand the Presentation Layer's Purpose

in this video I want to demystify the presentation layer of the clean architecture I'm going to explain what the presentation layer is and what responsibilities it should have and I'm also going to show you how to implement the presentation layer on an actual project the clean architecture is typically shown using concentric circles however it's still a layered architecture we have the domain layer at the core the application layer one level above and then we have the infrastructure and the presentation layer layers on the outskirts of the architecture and the presentation layer will be the focus of this video the presentation layer is responsible for interacting with the users of your application the implementation itself could be a restful web API a grpc service but it could also be a Blazer client application as I already said the presentation layer is the entry point into your system which means it's responsible for taking in incoming requests and then delegating the request to the appropriate components that are going to handle them the example I'm going to use to showcase the presentation layer will be a restful API built with.net and we're going to discuss API endpoints and the many ways that you can Implement them inside of asp.net core we're also going to talk about middleware and dependency injection setup we're going to start our discussion of the presentation layer from the web API project in my Run Tracker solution Run Tracker is an application that allows users to log their running workouts so that they can track progress over the training season it's implemented using clean architecture and you can clearly see the domain application and infrastructure project but where is the presentation project well in this case I named it the web API which is also the executable component of our system and it's what we're going to host on our servers and at the same time it's going to represent the presentation layer in our clean architecture implementation the core responsibility of the presentation layer is exposing and endpoints where the outside users can interact with our system in this example I'm using minimal API endpoints to Define post put delete and get endpoints for my API and you can see that all of my endpoints are really straightforward most endpoints have only three lines of code which revolves around taking in an incoming API request and mapping it to our respective command or query instance then we're going to use the iender service from mediator which is an in-memory messaging Library to send this command or query object to the respective Handler which is going to give us back the result of this operation and then based on the result value we can decide what we want to return from our minimal API endpoint this will function exactly the same if you wanted to use controllers and this idea in general is applicable to any implementation of the presentation layer so if this was a grpc service instead of an endpoint we would have a method stop with the request and response contracts and then we would be respons responsible for implementing the business Logic on the grpc server site this implementation places the API endpoints in the same project as our asp.net core web API and this has some implications as to what services your endpoints can reference for example I can freely take the application database context instance inside of my endpoints because this service is public and I need to reference it from my web API project in order to configure it with dependency injection so nothing is stopping me from injecting services that I normally shouldn't have access to into my endpoints and then doing something with them of course this is something that you can easily catch inside of a code review and shouldn't be much of a problem and my general rule of Thum for building API endpoints is to keep them as thin as possible so most of the time all I want to do is to take in a request turn that into some internal representation of the operation that I want to execute and then just run this operation and return the result in this example I'm using mediator to send a command object but this could just as well be a service class and I would be calling the respective method on this service nothing fundamentally changes because I'm using mediator but there are some other advantages that mediator brings which is why I like to use it in my applications we've seen the API endpoints but what are some other things that live inside of the presentation later if you're using asp.net core8 this is where you would Implement your Global exception Handler the the reason I said asp.net core 8 is because this is where we can access the I exception Handler interface which allows us to hook into the exception Handler middleware which is a built-in middleware for handling exceptions this interface exposes the try handle async method where I can Implement my Global exception handling code and in this case I'm catching any unhandled exceptions and I'm returning a problem details response from the API in some previous versions of net I would typically implement this using middleware and while we're on the topic of middleware let me also show you the request context logging middleware in this example this middleware is going to take a correlation ID from a respective incoming header or the trace identifier if the correlation ID isn't passed in and it's going to push this property into the seral log log context this is going to make this property available in all of my application logs for this request which is going to make them easily searchable later on if I want to figure out what went wrong with a particular request this is also where you would register your middleware in my case I have a middleware extensions class that wraps this into an extension method but I'm just going to call this from my program CS file to add this middleware to the request pipeline the program file is also going to be where we configure our services for the entire application for example I'm configuring sahog I'm adding my application and infrastructure Services wiring up the global exception Handler but I'm also taking care of API versioning this is also where I'm mapping my minimal API endpoints if I'm running in a development environment I'm going to configure my Swagger and Swagger user interface services and I'm also going to apply database migrations automatically to make my local development easier inside of this method I'm creating a custom service scope which I'm going to use to resolve the application database context and then I can run migrations using this context instance and this is going to apply my database migrations right as my application is starting up then we have our middleware configuration health checks and finally starting up the application instance so the presentation layer has a few distinct responsibilities revolving around actually running the application setting up the dependency injection because it acts as the composition route for our system but also exposing the respective API endpoints one more responsibility that's very important for the presentation layer is is setting up your application settings for this I'm using the built-in support of specifying my application settings using the app settings Json file this is where I set up my connection strings to the external services and for example I'm also using my application settings to configure my Cog setup so this is what a typical presentation layer implementation of the clean architecture would look like we are merging together the responsibilities of acting as a composition rout and also exposing the respective a Pi endpoints I want to show you a separate example that's using controllers so let's hop over to the other solution that I prepared you can see a very similar setup here where we are configuring the respective application Services wiring up any middleware but the one difference is we are mapping controllers instead of minimal API endpoints and if you take a look at the web application in this example you will see that there is no endpoints folder neither is there a controller folder for that matter because my API endpoints are defined outside of the executable application so if I go over to the training module for example this application uses the modular monolith architecture and the individual modules implement the clean architecture so you can combine these Concepts together but let's take a look at the endpoint project if I open up the invitations folder you will see I have an endpoint class inside for example this is the cancel invitation endpoint in this project I'm implementing the reaper pattern which stands for request endpoint response and I'm using the Ardis API endpoint snug package to implement this and this actually uses controllers and fluent generics under the hood to allow me to implement my API endpoints another popular library to implement this is fast endpoints but you'll notice that the implementation is more or less the same as in the example with the minimal apis that I just showed you so we are taking in a request object packaging that into a command instance and then sending it using mediator based on the result that we get back we're going to return our respective response from our API the reason I wanted to show you this example is so that you can see what it looks like when the API endpoints are defined outside of the asp.net core application this isn't very difficult to implement and it gives you greater control over what projects you can reference from the endpoint project and by combining this with the internal access modifier you can create some very strict design rules the other endpoints in this project are more or less the same you can see I'm using some Swatch Buckle annotations to expose more details in my open API specification this is also where we would take care of authenication and authorization in this case I'm using permission based authorization and the permissions themselves are defined in the endpoints project also instead of a static class and to show you how simple it is to Define your API endpoints outside of your as. net core web application here is everything you need to make this work the key component is calling the add application part method you're going to pass in an assembly instance that's going to contain your controller endpoints this particular assembly instance is defined inside of my endpoints project and if I show you the implementation this is just a static class with a static readon field called assembly and when I call add application part and I specify my endpoints assembly this is going to wire up any controllers inside of this project with the run time and the controller endpoints are going to be exposed on my API when it's running in this video I talked about the presentation layer of the clean architecture but if you want to learn how to implement the infrastructure layer then take a look at this video next make sure to smash the like button under this video and until next time stay awesome

Channel: Milan Jovanović

Views: 6,524

Keywords: clean architecture, clean architecture setup, clean architecture example, clean architecture .net, clean architecture cqrs, asp.net core, domain-driven design, clean architecture explained, software engineering, clean architecture .net core, software architecture, clean architecture asp.net core, clean architecture project setup, clean architecture asp.net core 7, clean architecture from scratch, clean architecture tutorial, clean architecture c#, minimal apis, rest apis

Id: trW-v4Gb0l0

Length: 10min 52sec (652 seconds)

Published: Fri Mar 22 2024