0

I want to know the best Practice is about having multiple dto’s for different use cases.

Let’s say we have an api with a set of controllers to handle requests coming from a administration backend and another set of controllers used for an mobile app. Behind the controllers we are running an onion architecture with mediatr (command/query).

We have an api call to receive a list of users returning UserModel. The logic goes into GetUsersQuery.cs. This call is used for the backend returning a list of users (name, age and username etc.)

But we also have en API call for the mobile app api where we want to return a list of users too, but we don’t want to expose username and some fields.

How would you handle name conventions for the dto and query/command classes in situations like this?

I assume I should create a new dto for the app api use case but I’m struggling with proper naming of the dto and query/commands.

Any good advice or smarter ways to handle/organize projects for these issues?

4
  • Unfortunately naming things is very subjective. As this question is phrased, it will likely be closed as opinion-based. Commented Jan 27, 2022 at 19:10
  • Hmm, maybe all you need is a GraphQL layer in between so the client can request the specific size and shape of the objects it needs and your service only works with the full spec object. I don't relish the maintenance of different DTO objects for the same concept. Commented Jan 27, 2022 at 22:54
  • Is this about naming things, or when to create a new class? Naming things is opinion-based, however the decision to create new, but similar classes might be on topic. Commented Jan 28, 2022 at 16:38
  • Using the same concepts for different contexts can simply be solved by using namespaces.
    – Rik D
    Commented Jan 31, 2022 at 18:52

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.