Is there any naming convention for IN and OUT DTO?

Viewed 4676

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!

1 Answers

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;
    }
Related