5 Rules For DTOs

Подписаться 12 тыс.

Просмотров 37 тыс.

50% 1

5 Rules for (better) DTOs
Hey everyone, I'm Steve Smith aka ardalis, of NimblePros!
In this video I'm going to tell you how to write better DTOs using 5 simple rules!
Let me know what you think or share your own tips in the comments below!
Get the Code
You can request the code used in this video here:
mailchi.mp/ardalis.com/5tipsdtos
Links
ardalis.com/dto-or-poco/
ardalis.com/web-api-dto-consi...
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
#csharp #dtos #dto #oop #dotnet #visualstudio #webapis #aspnet #aspnetcore

Наука

Опубликовано:

3 апр 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 117

@tomdanielsofficial 2 месяца назад

Summary: 1) DTOs should not have logic/behavior 1:03 2) DTOs should not enforce encapsulation. They don't need private/protected members. 7:26 3) DTOs should use properties (not fields), otherwise serialization won't work. 8:52 4) DTOs should only use "DTO" in their name as a last resort. Name them for how they are used. 10:13 5) These should be modeled as DTOs: 12:05 - API Request / Reponse objects - MVC ViewModel objects - Database query result objects - Messages (Commands, Events, Queries) * Record types can be helpful for DTOs * MVC models should be DTOs / MVVM models don't * Fluent Validation NuGet Package

@mrwalkan 2 месяца назад

Thanks

@meetingattender8132 2 месяца назад

This comment is better than the video thank you

@Ardalis 2 месяца назад

Thanks!

@pierwszywolnynick Месяц назад

you just saved me 17 minutes

@Ardalis Месяц назад

@@pierwszywolnynick What? Check this out: 1. Read this: ardalis.com/5-rules-dtos/ 2. It should save you at most 12 minutes because you can watch at 1.5x speed; 9 minutes if you watch at 2x 😁

@nrjmatta 2 месяца назад

Always a pleasure listening and watching your videos.

@Ardalis 2 месяца назад

Thanks!

@Robd515 2 месяца назад

Awesome quality video and very informative. Looking forward to exploring your videos for your expertise.

@Ardalis 2 месяца назад

Thanks!

@vadimemelin2941 2 месяца назад

Just what I was looking for! Cheers!

@Ardalis 2 месяца назад

Thanks!

@clairelist1060 2 месяца назад

Your explanation of why we might have a separate DTO for creating a resource vs accessing the resources some other way finally made sense to me!! Thanks!

@johnmaloney7174 2 месяца назад

I wonder why he used createdate as an example though instead of Id. Clearly you need to include Id (that wouldn't exist in the requestDto) in a responseDto.

@Ardalis 2 месяца назад

@@johnmaloney7174 Yes that's often true, too, especially for database-generated keys! There was no particular reason why I went with CreateDate aside from the fact that you basically never want some client to send that to your backend (rather than you controlling it) while in some cases you may be OK with client-generated keys (like with GUID keys).

@VishalTrivediB 2 месяца назад

Great tips, thank you very much!

@Ardalis 2 месяца назад

Glad it was helpful!

@fernandocalmet 2 месяца назад

Great video, Steve. Thank you for sharing

@Ardalis 2 месяца назад

Thanks!

@caseyspaulding Месяц назад

Great stuff. Thanks

@Ardalis Месяц назад

Glad you enjoyed it

@touabdelhak Месяц назад

Thanks for the content!

@Ardalis Месяц назад

My pleasure!

@Selbstzensur 2 месяца назад

Thank you for this Video. I really love c# as a programming language. For me it is the most complete one.

@Ardalis 2 месяца назад

You’re welcome and I love it as well.

@mumk 2 месяца назад

thanks for sharing!

@Ardalis 2 месяца назад

You're welcome!

@grzegorzborowski4284 Месяц назад

Great stuff. Would be nice to see more of your publicity.

@Ardalis 27 дней назад

Thanks! Yeah it's hard to schedule enough time to do these regularly around other commitments.

@TammamKoujan 2 месяца назад

Nice and clear video; I hoped that it talked about DTO mapping since it is an essential topic

@Ardalis 2 месяца назад

Thanks, I’ll try to cover that (and the fact that you can certainly have static helpers on your DTO types without breaking any of the rules) in a future video

@TammamKoujan 2 месяца назад

@@Ardalis , what I meant is that mapping is an essential topic for DTOs, and it would be a good addition to this video since people are using different approaches. Some use mapping libraries like AutoMapper, even though this is not widely recommended nowadays, while others do it manually. Personally, I use a combination of extension methods and Func Delegate with Expression.

@MrSupasonik 2 месяца назад

@@TammamKoujan I for one support the approach with extension methods, but could you elaborate please how do you use Func Delegates with Expressions?

@codefoxtrot 2 месяца назад

Very rich content for a video that could have easily been a mid-level course! Thanks Ardalis!

@Ardalis 2 месяца назад

Glad you liked it!

@OzgulEzgin 2 месяца назад

Thanks for the video Steve. May be you do a video on best practices for mapping dto's as well. Looking forward to it. Best regards.

@Ardalis 2 месяца назад

Great suggestion!

@theyuribanker 2 месяца назад

I need!!!

@DebugModeVideos 2 месяца назад

Thanks Steve

@Ardalis 2 месяца назад

You're welcome DJ!

@privatesocialhandle Месяц назад

No idea why some people are lemon. Thanks for taking the time to provide the knowledge.

@Ardalis Месяц назад

Thanks for watching!

@AndreNunes-ps5mc 2 месяца назад

great content!

@Ardalis 2 месяца назад

Thanks!

@theyuribanker 2 месяца назад

Thanks for sharing this rich content. I have a question about Repositroy. Do you intend to implement Unit Of Work pattern in Ardalis.Specification? or is it not good?

@Ardalis 2 месяца назад

On Specifications, no. On the Repository we ship in Ardalis.Specification package? I don't intend to do so but others can (and have). Honestly that Repository implementation is a bit of a monster because I've accepted just about every pull request from folks wanting "just one more" method on it, so it's no longer as tightly designed as I would prefer. Some day if I have time I may create an Ardalis.Repository that looks to fix this, but for now I have been living with the monster (and only using the bits I need) or just implementing a custom version in my customer's apps (which basically just means copying the base repository class and removing all the things they don't need).

@Ardalis Месяц назад

Article version: ardalis.com/5-rules-dtos/

@joshuawillis7874 Месяц назад

Good video! I'm kinda curious - do you think properties are considered more first-class for C# because of their syntactical sugar options (auto-props, get-only, init-only, etc.), or more for the original reason that they lowered into the common getter/setter pattern and regression, or is there another reason? It feels like the main reason to me is regression for getter/setter.

@Ardalis Месяц назад

All of the above? The language team keeps improving them. Tools and libraries typically work with them out of the box, by default, without additional configuration or hacks. Having proper property support was always one of the things that distinguished C# from Java (some more info here: stackoverflow.com/a/3430218/13729).

@alfonsdeda8912 2 месяца назад

Nice video! So if I have an entity that have some behavior with create method and validation in it is better to create a separate dto and a separate validator for this entity or is okay to use directly the entity if the behavior regards only the validation inside it self?

@Ardalis 2 месяца назад

If you’re creating the entity via some user input via an API or form Post, use a DTO for the over-the-wire data. Validate it and let the user know if they need to fix anything. Then call the Create method and pass it the parameters it needs from the DTO’s properties.

@alfonsdeda8912 2 месяца назад

@@Ardalis Is good to create an dto and populate from user form and pass directly to create method after validation instead of creating two separate classes?

@evildoer1606 2 месяца назад

What do you think about using record structs as DTOs? Seen it in some codebases. What are the pros and cons?

@Ardalis 2 месяца назад

I think record struct is basically an improved version of struct, and you should use it in 99% of the places where you might otherwise use a struct. Now, as to whether you should use a struct for your DTO types, I think this Stack Overflow question summarizes most of the use cases, and (TL;DR) recommends sticking with classes for most DTO use cases. stackoverflow.com/questions/11014501/dto-classes-vs-struct

@dallyoluwafemi2827 2 месяца назад

did you build the ardalis nugets?

@Ardalis 2 месяца назад

do you mean did I author them? yes, that's me.

@Devin-cf1jq 13 дней назад

Hi, what is the best practice here usually. Lets say we have an API service which accepts a request of a certain type (lets say DocumentRequest), So the Document request is a DTO. Should the consumer write the DTO on their side or should the author of the API expose the DTO, in form of a library or nuget, so that the consumer can simply add a reference and use. Asking this specially because with microservices if each microservice was to have a nuget (sort of like a client package) not sure if that is a good practice? What do you think? Thanks

@Ardalis 7 дней назад

It’s common in enterprises that use microservices for teams responsible for a microservice to also ship a client library, usually generated by NSwag or similar, which is updated any time a new version of the services is deployed. You don’t have to publish such things, and clients don’t have to use them. But they can make things easier and provide a supported path for other teams to use to integrate.

@AlwaysHCYT2 2 месяца назад

Attributes in record fields need "property:". In your example: [property:EmailAddress] string Email

@Ardalis 2 месяца назад

Yep, someone else mentioned that as well. Thanks!

@maciejwawoczny1174 Месяц назад

If my API return "UserResponse" which contain other class inside, how to name that inner class? class UserResponse { public InnerClassResponse/InnerClassDTO/InnerClass? } Same example with Requests etc

@Ardalis Месяц назад

Something like this: class CreateUserResponse { public UserDto User {get; set;} // other properties, metadata if needed } In some cases it might make sense to have a standard Response structure in which case the resulting data might always go into a "Payload" or "Result" property, which might be of type object or string.

@vasant2411 2 месяца назад

How should we name response object return from command

@Ardalis 2 месяца назад

CommandNameResponse probably

@JjKoller85 2 месяца назад

What is your take on inheritance on DTOs (especially Request and Response of WebAPIs)? I've seen it quite often in the past years. Following your first rule, I would assume that we rather should duplicate properties on DTOs?

@ddrsdiego 2 месяца назад

This is a really good question and given my years of experience in integrations I can say that starting with inheritance seemed to make sense but over time each endpoint starts to gain more life and management starts to become complex due to inheritance. What has worked for me is maintaining a canonical model and sharing it with all areas and yes, repeating properties in Requests and Responses

@Ardalis 2 месяца назад

I used to use inheritance for instance between a Create and an Update DTO I might have Update inherit from Create and just add an Id property (since db-generated Id wouldn’t be on a Create record). But it often turns out that’s not where the differences end and these days I just keep the types separate so there is no coupling between them. The duplication hasn’t caused me any troubles yet.

@mmuekk 2 месяца назад

I use interfaces instead inheritance

@jackeinstein2184 2 месяца назад

@@mmuekk could you please explain how?

@keesdewit1982 2 месяца назад

Rocky Balboa teaching me about DTOs. I love it 😅

@Ardalis 2 месяца назад

Heh, used to be folks thought I looked like Alec Baldwin from 30 Rock. Now with long hair I guess I'm Rocky... I'll take it. :)

@keesdewit1982 2 месяца назад

@@Ardalis You are just a nice guy ;) Thanks for providing these videos.

@rpo3ge 20 дней назад

So if I need some logic to be applied with the Dto data, would I map to another object first? Say we have fName lName properties Then I want to create a fullName property out of those, where’s the correct object to do that type of work?

@Ardalis 19 дней назад

Usually that would belong to a business entity (which is the thing persisted to the database). For instance maybe you have this: public class Person : BaseEntity { public string FirstName { get; init; } public string LastName {get; init; } public string FullName => $"{FirstName} {LastName}"; } Obviously this isn't a DTO because it doesn't have public setters and it has logic/behavior on it. You might create this entity from a DTO, so maybe your DTO has just fName and lName on it. Use that to create the Person instance and then save it with a DbContext.

@rpo3ge 19 дней назад

@@Ardalis thank you, so the models in the Core layer is where I could have behaviors For some reason I thought the models for persisting to a data store should be clean poco classes

@Ardalis 15 дней назад

@@rpo3ge you got it! I don't think a separate DTO layer for data mapping is necessary if your ORM can go directly from your domain entities (as EF Core can).

@johnmaloney7174 2 месяца назад

I would also suggest that your Data Access Layer only returns DTOs - that is, when using EF or EF with a Repo layer, that the DAL/Repo accepts and returns DTOs to/from the App layer. This way the app is clearly decoupled from entities/persistence & any business logic works exclusively with business models (dtos) . Both App & DAL would hold a reference to the Model project, but the App would not hold a reference to the DAL. Repo interfaces would be defined in the Model project but implemented in the DAL project.

@Ardalis 2 месяца назад

Repository is a DDD pattern. It's meant to work with the Domain Model, which includes your Entities and Aggregates. Those are the types it should accept/return, not DTOs. DTOs are typically an Application concern, and are used for ViewModels and API messages, etc. The only DTOs I typically have in my domain model are domain events. For simple apps you can just have your Web/UI layer use repositories, work with the domain model, and do whatever mapping is needed to DTOs. But for more complex apps (like ones that typically require DDD) I am typically using a UseCases project as my Application layer which does all the work of talking to the domain model and mapping DTOs. Then the web layer simply sends messages to the UseCases layer and gets back results with DTOs that are ready for it to use. See my Clean Architecture template on GitHub as an example.

@frontendtony Месяц назад

@Ardalis are we building the same app? Lol I'm relatively new to Dotnet/OOP/Design Patterns/Clean Architecture/etc, and I've settled on this structure you just explained because it made the most sense to me. Matter of fact, I use a separate "Common" project to store DTOs which I then create mappers for in the application layer to transform entities/queries/commands to their respective DTOs

@bensadik 2 месяца назад

I do the same thing, but I add mapping methods: record CreateItemRequest(string Name, string Value) { public Item ToEntity => new Item(Name, Value); }

@TammamKoujan 2 месяца назад

In this way, your DTO is doing more than just transferring data (Single Responsibility Principle); with more complex mapping scenarios, you will end up with a DTO that does many things out of its scope, is less flexible, and is less maintainable. Also, you are adding a dependency on your entity classes and tightly coupling them.

@henriquesouza5109 2 месяца назад

@@TammamKoujan Yeah, that's like putting the entity construction logic in the request object rather than in the entity constructor (where it should be in the first place). I prefer naming them "Input/Parameters" rather than Request/Dto etc since Request is usually bound to http domain and Dto doesn't mean anything at all. If you have a constructor "Item(string name, string value)" and you wanna expose this interface to the http (remember http is just a layer on top of your application), then what happens is you create a class to wrap exactly "name" and "value" function parameters, so why don't you name it so? CreateItem is the function, and name + value are the parameters, therefore CreateItemParameters, CreateItemParams or CreateItemInput (in Input/Output pov).

@Ardalis 2 месяца назад

Adding static helpers to map to/from other types is fine IMO. Extension methods probably even better, though. Avoid instance methods since those break first rule and introduce issues others are commenting on.

@bensadik 2 месяца назад

@@Ardalis extension methods are a great idea for this particular purpose, but it’s only a C# thing, for other languages this is just fine IMO

@scotmcpherson Месяц назад

These rules although great for abstraction, have an impact of runtime efficiency. When a server is dealing with lots of lots of concurrent realtime data streams, this can have a negative impact.

@Ardalis Месяц назад

Which?

@scotmcpherson Месяц назад

@@Ardalis Have you ever looked at runtime optimized code? It's not organized, and can be hard to read. Prototyping with organization is important, but once you go into release, if it needs every sliver of performance, then your organization gets torn to shreds.

@AlFasGD 2 месяца назад

I strongly disagree with the point about using properties over fields. Properties are very cumbersome to write, and fields are straight-foward. You can setup your serializer of your choice (Newtonsoft, System.Text, or any other) to also discover the fields in your DTO. The only drawback that fields have is that they do not implement interfaces, and in the case that your DTO implements one, you have to stick to properties. Speaking of interfaces, you did not touch the subject of having all those common fields like ID, email, first and last names, etc. Oftentimes you are mapping them out individually, having more boilerplate code for passing all that information around, than actually using and processing it. Sometimes, it might come in handy to use interfaces to abstract away that responsibility of mapping objects like this, and allow for multiple objects to be mapped out via their interface properties.

@spacemanjack777 2 месяца назад

Writing properties is cumbersome... really? But a custom serializer configuration instead of ordinary properties and be done with it? Yes, properties takes a few more characters to type than fields, but most of the time nobody is actually typing in those are they? I mean, code intellisense.

@AlFasGD 2 месяца назад

@@spacemanjack777 whatever you do to make your property declaration process shorter, it's still longer than fields. That's all.

@Ardalis 2 месяца назад

Properties are trivial to write these days and almost always auto-completed by your IDE or else easily copy/pasted when you're creating several of them. Leveraging the default behavior of the framework instead of requiring customization is way more valuable than trying to save a few characters on declaring your class members, IMO. But if it's working for you, go for it.

@anomalii7720 2 месяца назад

But, for the record, it's your 5 rules. And that doesn't mean anything. 🙂

@chudchadanstud 2 месяца назад

🙃

@Ardalis 2 месяца назад

What did you expect it to mean? All rules are made up by someone.

@privatesocialhandle Месяц назад

You're constructive.

@ghevisartor6005 14 дней назад

How can a video on dtos trigger you so much?

@wandie87 2 месяца назад

Great video. I typically end up with multiple DTOs (Whether these are Request or Response types) for specific use cases. For example: UserResponse.cs UserWithAddressResponse.cs UserWithBirthdateResponse.cs Each response would be used for a different API request to ensure I am only sending the required information back over the wire (no oversharing). Is this problematic? If so, how would be best to improve upon this? I feel I end up with a lot of replicated code... Thanks

@Ardalis 2 месяца назад

I'm with you. I'd rather have independent DTOs for different API endpoints with a bit of duplication between them but no coupling than have some inheritance hierarchy that might bite me later with an unforeseen consequence of sharing. I've been building APIs for a LONG time and my trend has been toward increasingly independent endpoints. In the beginning, like most .NET devs of the time, I had big controllers with big DTOs and minimal duplication (DRY all the things!) but now I use API Endpoints (usually fast-endpoints.com) with bespoke Request and Response DTOs for each endpoint (REPR Pattern) and I've found this makes it MUCH easier to build and modify individual endpoints without risk of breaking others.

@wandie87 2 месяца назад

@@Ardalis I agree. How do you deal with nested DTOs? Take my UserWithAddressResponse.cs example above. Do you have a child DTO for address that you reference or do you do it all in the single top level DTO? If the child reference route, is this shared between other DTOs or bespoke to the user object?

@Ardalis 2 месяца назад

@@wandie87 Probably an AddressDTO with the basics, and an array of them for the UserWithAddress (assuming they have more than one) or just a property if only the one. I've never really thought about my personal "rules" for such things but thinking about it now I tend to create very simple "FooDTO" types for "leaf node" objects that have no references to other objects (especially collections). These will usually live in my UseCases/Application layer since that layer is usually responsible for returning them to the UI layer in response to queries/commands/messages sent to it. The leaf node DTOs are (somewhat) reusable, and may be (re)used to compose more custom Request/Response etc DTOs. The more complex DTOs (like UserWithAddress for instance) are usually less reusable and more customized to a particular operation.

@wandie87 2 месяца назад

@@Ardalis I’d never put much thought into it either until I watched your video. Triggered me to have a think about how I structure this stuff going forward and augment some of my own rules into the ones you provided.

@doubleMSW 2 месяца назад

If you're using EF Core and reference the id from one "DTO" to another (i.e. OrderDTO, OrderItemDTO, ProductDTO) in EF Core I've aways seen a reference in the DTO: public class OrderDTO { public Guid Id { get; init; } public string OrderNumber { get; init; } ... // If you had a many to many there would be reference to a collection from a link entity // If you had a one to many there would be a reference to a collection of the many side (i.e. OrderDTO and OrderItemDTO which linked to a ProductDTO) } public class OrderLineItemDTO { public Guid Id { get; init; } public Guid OrderId { get; init; } public int ItemNumber { get; init; } ... public OrderDTO Order { get; set; } public ICollection LinkOrderItemProductCollection { get; set; } } I don't want to continue down the rabbit hole here, hopefully you get the jest of what I'm referring too... Thoughts???

@Ardalis 2 месяца назад

EF Core shouldn’t be working with DTOs directly - I assume you’re talking about mapping entities to DTOs, right?

@doubleMSW 2 месяца назад

@@Ardalis correct

@johnmaloney7174 2 месяца назад

It's a good question, but the navigation properties that exist on entity object don't need to exist on the dto. If you use Automapper, it will populate those properties with the related objects/object collections without hassle.

@Ardalis 2 месяца назад

@@johnmaloney7174 Exactly. Sometimes you'll want the related objects in the DTO structure, sometimes you might just want the IDs. For instance when getting a collection of Orders from a GET /orders endpoint you might only get the top level order info, but then if you GET /orders/123 you will often get additional information including the details of the line items. The "shape" of your DTO data will often vary with context, and won't often correspond directly to your domain entity or data model.