C# Dto constructor and dependency injection

Question

I would like to know what is the best practice in designing the constructors of DTO objects.

say i have a Dto object like this:

class CustomerDto
{
    public string Name { get; set; }
    public string Surname { get; set; }
    public string Phone { get; set; }
    ...
}

There are several ways to construct the object:

I could declare a constructor:

public CustomerDto(string name, string surname, string phone, ...)
{
    this.Name = name;
    this.Surname = surname;
    this.Phone = phone;
    ...
}

When you see this constructor and immediately conclude a SRP (Single responsibility) violation?

Even though these attributes are all related.

One could also argue there is no need to validate the properties as this is a DTO and has NO behavior, and the behavior should rather be on the domain object that this maps from.

In C# we can also more elegantly construct this object:

var dto = new CustomerDto ()
{
    Name = "Some name",
    Surname = "Some surname"
}

Or use a fluent builder or a framework such as NBuilder.

There is also the usage of Auto mapping frameworks like Automapper. The problem is also using an Ioc container the ctor becomes complex, as well as the risk in swapping arguments for example, you pass in name where surname is or vice versa, the validation could miss this more easy then explicit mapping as above.

Please help convince me which is the better way.

Answer 1

Value types as in your examples aren't dependencies. A dependency provides a functionality (or configuration) to the consumer. In your case they are just normal values that are assigned to your DTO. As long as the data belongs together you do not violate SRP even if you assign a lot of values in the constructor. The single responsibility in this case is to hold the data.

Also DTO's shouldn't be created by a IoC container and have no real dependencies. You should create them manually, by your persistency framework or using auto mapping.

If assigning the values using a constructor or properties is better depends on the usage. If they are required the constructor variant is better. If they are optional the property way is better.

Answer 2

I would suggest using immutable data structures so DTO entity would not expose any setters, obviously in this way constructor should provide ability to initialize all underlying properties of a given DTO.

So I prefer:

public CustomerDto(string name, string surname, string phone, ...) 

DTO is a Data Transfer Object, especially to represent a set of properties to be passed across a system (distributed as well) boundaries, so do not bother too much regarding SRP violation. This is like Facade design pattern, it abstarcts a set of operations/services to simplify usage. So in this kase Keep It Simple won.