DTO naming conventions , modeling and inheritance

Question

We are building a web app using AngularJS , C# , ASP.Net Web API and Fluent NHibernate. We have decided to use DTOs to transfer data to the presentation layer ( angular views). I had a few doubts regarding the general structuring and naming of DTOs. Here's an example to illustrate my scenario. Lets say I have a domain entity called Customer which looks like:

public class Customer
    {
        public virtual int Id { get; set; }
        public virtual string Name { get; set; }
        public virtual Address Address { get; set; }
        public virtual ICollection<Account> Accounts { get; set; }
    }

Now, in my views/presentation layer I need to retrieve different flavors of Customer like :

1) Just Id and Name 2) Id , Name and Address 3) Id , Name , Address and Accounts

I have created a set of DTOs to accomplish this :

public class CustomerEntry
{
    public  int Id { get; set; }
    public  string Name { get; set; }
}

public class CustomerWithAddress : CustomerEntry
{
    public AddressDetails Address { get; set; }
}

public class CustomerWithAddressAndAccounts : CustomerWithAddress
{
    public ICollection<AccountDetails> Accounts { get; set; }
}

AddressDetails and AccountDetails are DTOs which have all the properties of their corresponding Domain entities.

This works fine for querying and data retrievals ; the question is what do I use for inserts and updates. During creation of a new customer record , name and address are mandatory and accounts are optional ..so in other words I need an object with all the customer properties. Hence the confusion :

1) What do I use for insert and updates? The CustomerWithAddressAndAccounts DTO has everything in it but its name seems a bit awkward to be used for insert/updates.

2) Do I create another DTO .. if I do , wouldn't that be duplication as the new DTO will exactly be like CustomerWithAddressAndAccounts ?

3) Last but not least , does the DTO inheritance strcuture described above seem like a good fit for the requirement ? Are there any other ways to model this ?

I have gone through other posts on this topic but couldn't make much headway. One thing that I did pickup was to avoid using the suffix "DTO" in the class names. I think it feels a bit superfluous.

Would love to hear your thoughts

Thanks

Answer 1

Recommendation is that you should just have one DTO class for each entity suffixed with DTO e.g. CustomerEntryDTO for the Customer entity (but you can certainly use inheritance hierarchies as per choice and requirements).

Moreover, Add a abstract DTOBase kind of base class or an interface; and do not use such deep inheritance heirarchies for each Address, Account and other properties to be included in child DTOs. Rather, include these properties in the same CustomerEntryDTO class (if possible) as below:

[Serializable]
public class CustomerEntryDTO : DTOBase, IAddressDetails, IAccountDetails
{
    public  int Id { get; set; }
    public  string Name { get; set; }
    public AddressDetails Address { get; set; } //Can remain null for some Customers
    public ICollection<AccountDetails> Accounts { get; set; } //Can remain null for some Customemer
}

Moreover, your DTOs should be serializable to be passed across process boundaries.

For more on the DTO pattern, refer below articles:

Data Transfer Object

MSDN

Edit: In case you don't want to send certain properties over the wire (I know you would need to that conditionally so would need to explore more on this), you can exclude them from the Serialization mechanism by using attributes such as NonSerialized (but it works only on fields and not properties, see workaround article for using with properties: NonSerialized on property). You can also create your own custom attribute such as ExcludeFromSerializationAttribute and apply it to properties you don't want to send every time over wire based on certain rules/conditions. Also see: Conditional xml serialization

Edit 2: Use interfaces for separating the different properties in the one CustomerEntryDTO class. See the Interface Segregation Principle on Google or MSDN. I will try to put a sample explanation later.

Answer 2

What do I use for insert and updates?

1. Service operations are usually defined in very close relation to business operations. Business language doesn't speak in terms of "inserts" and "updates", neither do services.

2. Customer management service is likely to have some Register operation that takes customer name and maybe some other optional parameters.

Do I create another DTO?

Yes, you should create another DTO.

Sometimes service operation contract may be enough and there is no need to define a separate DTO for a particular operation:

function Register(UserName as String, Address as Maybe(of String)) as Response

But most of the time it is better to define a separate DTO class even for only a single service operation:

class RegisterCommand
    public UserName as String
    public Address as Maybe(of String)
end class

function Register(Command as RegisterCommand) as Response

RegisterCommand DTO may look very similar to CustomerWithAddress DTO because it has the same fields but in fact these 2 DTOs have very different meanings and do not substitute each other.

For example, CustomerWithAddress contains AddressDetails, while a simple String address representation may be enough to register a customer.

Using a separate DTO for each service operation takes more time to write but easier to maintain.