title: DTO naming conventions , modeling and inheritance
body: <p>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:</p>
  
  <pre><code>public class Customer
      {
          public virtual int Id { get; set; }
          public virtual string Name { get; set; }
          public virtual Address Address { get; set; }
          public virtual ICollection&lt;Account&gt; Accounts { get; set; }
      }
  </code></pre>
  
  <p>Now, in my views/presentation layer I need to retrieve different flavors of Customer like :</p>
  
  <p>1) Just Id and Name
     2) Id , Name and Address
     3) Id , Name , Address and Accounts</p>
  
  <p>I have created a set of DTOs to accomplish this :</p>
  
  <pre><code>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&lt;AccountDetails&gt; Accounts { get; set; }
  }
  </code></pre>
  
  <p>AddressDetails and AccountDetails are DTOs which have all the properties of their corresponding Domain entities.</p>
  
  <p>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 :</p>
  
  <p>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. </p>
  
  <p>2) Do I create another DTO .. if I do , wouldn't that be duplication as the new DTO will exactly be like CustomerWithAddressAndAccounts ?</p>
  
  <p>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 ?</p>
  
  <p>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.</p>
  
  <p>Would love to hear your thoughts</p>
  
  <p>Thanks </p>