REPR and Clean Architecture

REPR and Clean Architecture
Hey everyone, I'm Steve Smith aka ardalis, of NimblePros!
In this video I introduce you to the REPR design pattern and show how I use it in my Clean Architecture solution template. I've found that it has dramatically improved the organization of my API endpoints in many different projects and I've heard from many developers that it's helped them as well.
Let me know what you think or share your own tips in the comments below!
Links
ardalis.com/moving-from-contr...
ardalis.com/mvc-controllers-a...
deviq.com/design-patterns/rep...
github.com/ardalis/ApiEndpoints
fast-endpoints.com/
github.com/ardalis/CleanArchi...
Check out my courses:
dometrain.com/course/getting-...
dometrain.com/course/deep-div...
ardalis.com/training-classes/
www.pluralsight.com/authors/s...
Team Consulting and Training: NimblePros.com and @nimblepros
Developer Group Mentoring: devBetter.com
Free Weekly Email Tips:
ardalis.com/tips/
If you read this far, I hope you liked this video and will consider subscribing to my channel!
Find me:
ardalis.com
/ ardalis
github.com/ardalis
/ stevenandrewsmith
bsky.app/profile/ardalis.com
#mvc #modelviewcontroller #razorpages #aspnet #aspnetcore #dotnet #visualstudio #apiendpoints #fastendpoints #cleanarchitecture #designpatterns #webapis #minimalapis

[@carlosportillo6915]

Thank you very much, I will implement it in my new project.

[@Ardalis]

Great!

[@darylolson5089]

I've watched many of your courses on Pluralsight and they were excellent. I just started building an application based on the Modular Monolith concept with your Clean Arch template as the starting point. Just bought your "Modular Monoliths - Deep Dive". Looking forward to diving in.

[@Ardalis]

Great to hear!

[@gregorymeadows3572]

Been following this pattern without knowing what it was called. This video should make things a lot easier to get the rest of my team to understand what and why we do things this way.

[@Ardalis]

Glad I could help!

[@Mariobot]

Nice Channel, thanks for share.

[@Ardalis]

Thanks for visiting!

[@osmantas369]

@ardalis hi. I like the style you explain stuff. Could you please briefly compare the repr approach with the nextjs endpoint structure? IMHO there are some kind of similarities.

[@Ardalis]

I understand there are similarities and that the minimal api feature the aspnet built was also influenced by nextjs. However I haven’t used nextjs myself at all so I can’t comment beyond that I’m afraid.

[@rodwinify]

@ardalis Hi Steve. Great content as always. Question, what is the value of having a fast endpoint response where the use case already returns a dto. e.g. Response = new UpdateProjectResponse(new ProjectRecord(dto.Id, dto.Name));. thanks

[@Ardalis]

Mostly just to reduce coupling. If you wanted you could use the use case dtos (and probably the commands and queries) as your api requests/responses. But you give up flexibility at least for public apis with clients you don’t want to break all the time. If you own the client (for example a spa which is your only client app) then the decoupling is less worthwhile. Hope that helps!

[@sanampakuwal]

Cool, just my question is why not use minimal apis directly?

[@Ardalis]

They tend to be a mess once you have more than a few of them. Organizing the endpoints in folders and files is better for many reasons (in my opinion). Fewer merge conflicts, easier to find things, etc.

[@_rcs]

How to you decide whether to send a message via MediatR vs performing logic directly in HandleAsync?

[@Ardalis]

Lately I’ve been leaning toward messages by default so I can use behaviors for cross cutting concerns consistently throughout the app. I talked about that in a previous video.

[@mostafadindar2699]

Thank you, I'm wondering why still using MediatR in the solution template while we already using FastEndpoint?

[@Ardalis]

I'm only relying on FastEndpoint for my UI layer, not my full application logic. I like the library but I'm not ready to completely marry it for all of my app's needs :). So I prefer having a separate project for UseCases/Application layer where I can leverage MediatR and Behaviors for cross-cutting concerns. I have some other videos showing this that you might check out.

[@sttrife]

A question about the response classes for endpoints. In our (REST) api projects, the Add, Update, Get-All, Get-One would normally return the 'viewmodel' of that entity. With the REPR, would that mean we would have to recreate the viewmodel 4 times (once for each request) and update it 4 times if anything is changed? That seems less convenient, how do you deal with those situations?

[@Ardalis]

Similar to my answer to @maciejwoczny1174, if you're following REST and therefore need to represent the state of Resources (typical), then it's fine to include a representation of the Resource as a property of your Request and Response types. It's likely you still want to have a separate request for Create/POST vs. Update/PUT, and for hierarchical data, it's also likely you'd return a different (smaller) representation of each resource from a List/GET (all) endpoint than from a GetById/GET{id} (details) endpoint. Using separate Response types lets you compose your API in a way that allows you to provide the right amount/shape of data in each scenario.

[@sttrife]

@@Ardalis as in: include the viewmodel as 'data' property or something similar? What about deriving the requestmodels for update and create endpoints from a common viewmodel?

[@Ardalis]

@@sttrife you can; I don’t typically bother these days because the coupling can be worse than the duplication. It’s up to you how you treat that tradeoff

[@christpetitjean]

Great but in clean architecture, your mediatr requests returns domain models or DTOs. With this approach, you add mapping logic into presentation layer. Isn't this supposed to part of business also ? In fact I am wondering where is the best place to put all this logic.... (or even if we should consider "dumb" mapping as logic...) What do you think ?

[@Ardalis]

I'm mostly having my UseCases project act as my Application layer and perform the required mapping to/from DTOs for the UI. So requests come in that use UI-level DTOs like CreateUserRequest. They get validated at the UI level using model binding, etc. Then they're mapped to a CreateUserCommand which is defined in the UseCases project, which also has the handler for that command. In the handler, it works with the domain model, including entity/aggregate types and abstractions like a Repository if necessary. In this case, a User entity is created (in a successful case), and the entity is mapped to a UserDTO or UserDetails type which is then returned to the UI layer, which incorporates that into a UserCreatedResponse either directly (public UserDTO User) or via mapping to a UI-level DTO. Usually I find I don't need a separate UI-level DTO for simple types but there may be multiple UI-level DTOs for different views of hierarchical types. For instance ListUsers might just return Ids and names while GetUser might return the User along with all of its child collections (addresses, claims, whatever) and so each of these would work with different DTOs. But again these separate DTOs might easily be defined in the UseCases project which is responsible for doing the work of getting the data for the request. HTH

[@brandonpearman9218]

Standard MVC is actually super simple. The problem statement does not seem strong enough. Just seems like trying to be different for different sake.

[@Ardalis]

It’s just applying Single Responsibility Principle and cohesion to your API endpoints and resulting in smaller better-factored classes that have fewer merge conflicts and are easier to locate and maintain.

[@brandonpearman9218]

@@Ardalis solution to merge conflicts is CI. Ive worked on very large projects and have had up to 15devs to using the same code base, merge conflicts is not a problem when devs stick to ci. Most devs navigate faster with controllers and no mediatr. You learn this if you pair a lot. You see how people navigate and where they struggle... controllers is not a struggle for any dev. Some have said they don't like it but that's different to struggling with it. Some of our services are simple classes, while others have mediatr, fluent validation and other packages. The efficency difference is night and day. The biggest problem is too many useless patterns. Because its cool to use patterns and devs want experience in all gof patterns, other popular KZbin patterns.

[@krccmsitp2884]

MVC might be a good fit for CRUD-centric applications, but Minimal API (and REPR) are a better fit for Domain-centric applications.

[@AlgoristHQ]

@@krccmsitp2884 why?

[@brandonpearman9218]

@@krccmsitp2884 Sorry, need some reasoning. Cant just accept it on "because I said so"

[@margosdesarian]

But Steve ... what are the "good reasons why you might want to do that" ....?

[@Ardalis]

Remind me what I was talking about or give me a timestamp; maybe I’ll do a follow up vid

[@margosdesarian]

@@Ardalis It was at 9:38 .. speaking about Mediatr

[@steve-ardalis-smith]

@@margosdesarian Ah, got it thanks. Yes I meant why you might want to have separate Use Case handlers to do the bulk of the work, rather than doing more of it in the endpoint itself. Reasons you might want to do this include separate of concerns, easier testing, code organization, etc. but even more important than all of that is the ability to leverage the chain of responsibility pattern to easily take care of cross-cutting concerns around your business logic such as validation, caching, error handling, logging, and more. I talk about this more here: kzbin.info/www/bejne/qKDaZ5V7pLChaJI

[@marcobaccaro]

No, thanks. It doesn't solve any problem; it just creates another buzzword, promotes Mediatr, and way more files.

[@Ardalis]

Having words to describe things is how language works. You don’t have to use MediatR to use REPR - FastEndpoints has everything you need or it’s not hard to roll your own. More, smaller files works better with source control and is less likely to violate SRP, separation of concerns, or bloated classes. But if you don’t like that style, don’t use it.

[@artemvolsh387]

@@Ardalis It's one of the best responses I've seen to comment like this. Thanks for the content, btw