DTO to UI, or not?
-
A simple question with not that simple answer. Do you bind your dto classes directly to the UI (web page, rest API deserialization etc...), or you use a middle layer of object/properties between the dto and the UI? Thanks!
Advertise here – minimum three posts per day are guaranteed.
-
A simple question with not that simple answer. Do you bind your dto classes directly to the UI (web page, rest API deserialization etc...), or you use a middle layer of object/properties between the dto and the UI? Thanks!
Advertise here – minimum three posts per day are guaranteed.
A "DTO" be definition is a (Data Transport) "middle layer" (Object).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
A "DTO" be definition is a (Data Transport) "middle layer" (Object).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Data transfer objects. It's an architectural pattern in .Net Core, Java etc.
Advertise here – minimum three posts per day are guaranteed.
-
A simple question with not that simple answer. Do you bind your dto classes directly to the UI (web page, rest API deserialization etc...), or you use a middle layer of object/properties between the dto and the UI? Thanks!
Advertise here – minimum three posts per day are guaranteed.
As always, "it depends". If the data is simple enough and the view doesn't need any additional data for other UI elements, like filling in options for a dropdown, you could get away with using the DTO's in the UI. If your UI is more complex, you'd be better off building a view model to hold the data and any additional information needed to build out the UI. Typically, I don't use DTO's to do anything other that talk to the datasources.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
As always, "it depends". If the data is simple enough and the view doesn't need any additional data for other UI elements, like filling in options for a dropdown, you could get away with using the DTO's in the UI. If your UI is more complex, you'd be better off building a view model to hold the data and any additional information needed to build out the UI. Typically, I don't use DTO's to do anything other that talk to the datasources.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakThanks!
Advertise here – minimum three posts per day are guaranteed.
-
A simple question with not that simple answer. Do you bind your dto classes directly to the UI (web page, rest API deserialization etc...), or you use a middle layer of object/properties between the dto and the UI? Thanks!
Advertise here – minimum three posts per day are guaranteed.
I think the real answer is unfortunately yes it goes in the UI. What happens is that the start up does it that way because it is quick. And they keep doing it quick even after they have funding. And even after they start hacking the DTOs into morphed states that make it confusing as to what is going on (or even where the DTOs live in the code stack.) Then 5 years in when the application becomes large then everyone complains about why the interfaces are not clean but no one, and I mean no one, wants to do the major refactor that would be required to separate the different functional units (and provide appropriate DTOs for each.) Of course eventually, if the company lasts, then it gets so big that the have to re-write major portions. ...but they want to do that quick.