Is there any naming convention for IN and OUT DTO?

Question

If I had to create some sort of API with a MVC architechture, I would have to decide a naming convention for DTOs that the controller receive and those DTOs that the controller produces I'm right?

For example, given the following code:

public class InStudentDTO
{
    public int Id { get; set; }
    public List<int> Grades { get; set; }
}

public class OutStudentDTO
{
    public int Id { get; set; }
    public bool HasApprovedCourse { get; set; }
}

[HttpPost]
public OutStudentDto StudentHasApprovedCourse(InStudentDto dto)
{
    OutStudentDto outStudentDto = _someService.CalculateStudentApprovedCourse(dto);
    return outStudentDto;
}

This is just a silly example, but the point is that I want to perform some calculation inside a service with the property List<int> Grades and not showing it later on the output of the controller. Thus, as far as I understand I should create a brand new DTO only that doesn't expose the List<int> Grades property, right? If so, how is the right naming convention to this "produced DTOs¨? or should just name those as Viewmodels?

Thanks!

Answer 1

There is no single standard or naming convention for naming DTO types because it's an implementation concern - I'm not aware of the ASP.NET Web API team endorsing any particular convention either (there's also plenty of bad examples of using actual Entity Framework entity-types as DTOs in the official ASP.NET documentation (DON'T DO THAT for many reasons - unless you know what you're doing)).

However, I have noticed a general trend in the .NET developer community that "In" DTOs (as you call them) are often named ${ResourceName}Request and "out" output/response DTOs are often named ${Resource/Action}Response - it's also not uncommon to have "Dto" as a type-name suffix.

However, when it comes to naming-conventions and coding-style it's _generally more important to be consistent than it is to be "correct" - so if your existing project uses Dto as a suffix then do that, but if your project doesn't use a suffix then don't start using one (without a good reason).

Also, avoid ambiguous names like Id - use the full name (StudentId) instead.

In my subjective opinion, given your example, I would name them like so:

public class StudentCourseApprovalRequestDto
{
    public int       StudentId { get; set; }
    public List<int> Grades    { get; set; }
}

public class StudentCourseApprovalResponseDto
{
    public int  StudentId         { get; set; }
    public bool HasApprovedCourse { get; set; }
}

[HttpGet]
public StudentCourseApprovalResponseDto StudentHasApprovedCourse( StudentCourseApprovalRequestDto req )
{
    StudentCourseApprovalResponseDto resp  = _someService.CalculateStudentApprovedCourse( req );
    return resp;
}