DTO support / models & controllers isolation / serialization mechanism
See original GitHub issueHello there!
I’m trying to figure out how to apply JADNC to a bit more complicated cases.
- For example, we have one model Post that could be updated from multiple endpoints
/api/admin/*
and/api/client/*
. In this case model class should stay the same, but payloads for those endpoints should be different:/api/client/*
payload:{ "text": "...", "name": "..." }
/api/admin/*
payload:{ "text": "...", name: "...", "showOnMainPage": true }
The case makes me thinking of using 2 different DTO objects here: AdminPostDto
and ClientPostDto
, but how I can say to the controller to use ClientPostDto
as input parameter for CreateAsync
action and return Post
object itself after the creation? The default behaviour says that Post
object is expected as input and as output. Is that possible to change this rule somehow?
- How I can expose different attributes from the same model, but for the different controllers. For example, Client app should not receive
showOnMainPage
property, but it’s needed within Admin app
Thanks!
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Service layer returns DTO to controller but need it ...
The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need simple objects without complex logic.
Read more >Practical PHP Patterns: Data Transfer Object
Their further evolution involves then serialization mechanisms; of course both the provenience and the destination of a Data Transfer Object ...
Read more >NestJS transform a property using ValidationPipe before ...
If I camelcase them, then class validator is happy. Is this a symptom of the transform not running before the validation occurs? This...
Read more >Performance Evaluation of Serializable Snapshot Isolation ...
PDF | Snapshot Isolation (SI) is a multiversion concurrency control protocol, allowing the concurrent transactions to consult older versions ...
Read more >Rules to Better Clean Architecture
Having Clean Architecture enables changes to have isolated impact, and allows for the system to be easily extended and maintained.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Read the fundamentals of REST at https://en.wikipedia.org/wiki/Representational_state_transfer. You cannot have two variants of one resource, that would break all caching. So you can have either a single Post resource (at a single URL) or have both AdminPost and UserPost (which are two unrelated resources at different URLs). Serving the same resource at two different URLs breaks the concept of resources with CRUD operations, which is what JSON:API describes.
Resources in JSON:API are more like EF Core entities, not at all like DTOs or view models (which typically have a different structure at each endpoint).
Perhaps you are unaware that JADNC implements the JSON:API specification. That spec defines rules on how URLs, operations, query strings, and payloads are structured. For example, there is no PUT support. Partial patch enables to partially update a subset of resource fields.
I’ve made my point and pointed you in the right direction. Of course, you can build any API you want, but if you’d like to use JADNC then I suggest you read up a bit on the basics instead of asking questions like these.