.Net Core Api - multiple Dto’s for single entity

Question

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?

• Greg Burghardt: Unfortunately naming things is very subjective. As this question is phrased, it will likely be closed as opinion-based.
• Berin Loritsch: 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.
• Greg Burghardt: 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.
• Rik D: Using the same concepts for different contexts can simply be solved by using namespaces.