1

I'm currently creating a small single page app for myself. I'm using Angular and ASP.Net Core 2 Web API. On the server side, I'm also using the DDD approach (just for learning purposes, the app isn't big enough for using DDD reasonably), therefore I'm mapping my Domain Entities to DTOs.

Here is an example of an domain object, which represents a learning question, I called it "Fact":

   public class Fact : AggregateRoot
    {
        public Fact(
            string id,
            string questionText,
            string anwerText,
            DateTime creationDate) : base(id)
        {
            Guard.StringNotNullOrEmpty(() => questionText);

            QuestionText = questionText;
            AnswerText = anwerText;
            CreationDate = creationDate;
        }

        public string AnswerText { get; private set; }
        public DateTime CreationDate { get; private set; }
        public string QuestionText { get; private set; }
    }

On a sidenode: It is deserialized and serialized for MongoDB, that's why the setters are private, since it can't deserialize readonly properties.

Now, one interesting thing, I didn't find a conclusive answer for: I see two possibilites to shape Domain Entities to DTOs:

  • The academic REST approach, therefore my FactsController would return pretty much a FactDto, which has all (or almost all) propertes of the Domain object above
  • I map it to the needs of my single pag app, for example FactEditDto, FactOverviewEntryDto, etc. Therefore more of the ViewModel approach

I've seen both approaches, and thinking about it, I see cons and pros for both ways:

One ressource DTO per entity:

  • Reusability, I guess for example VSTS is using the same REST Service I can call for the UI as well
  • Applies the REST principles better

DTO per "View":

  • Smaller JSON files, more efficent
  • Mapping can be done on the server, for example via AutoMapper
  • Easier to communicate for specific data, for example I could concat sub ressources into a DTO or pass an "action" with all needed data
  • Very little reusability

A very interesting example is from Microsoft itself: https://docs.microsoft.com/en-us/aspnet/web-api/overview/data/using-web-api-with-entity-framework/part-5 In this, they send two DTOs, one for the Details, which also doesn't seem very REST like?

Is there a public consesus regarding that topic and the tradeoffs of both possibilities?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.