non-persistent properties in domain data model

Question

I hear that for a small project DTO's are not recommended for example here and here. I wonder if it is OK for a considerably small project (team-wise) to merge non-persistent properties in the domain models? eg:

namespace Domain.Entities
{
    public class Candidate : BaseEntity
    {
        public Candidate()
        {
            // some construction codes
        }

        // region persistent properties

        public string FirstName { get; set; }
        public string LastName { get; set; }
        public bool? IsMale { get; set; }
        public DateTime BirthDate { get; set; }
        // other properties ...


        // region non-persistent properties
        public string FullName => $"{FirstName} {LastName}";
    }
}

Is this just keeping simple or am loosing anything valuable this way?

Its good to have all methods in one place of course, but I guess this confuses persistence. It all depends on how you read data and persist data. — NoChance, Nov 09 '18 at 13:30
If you do this you'll need to mark the non-persistent properties as `[NotMapped()]` or `.Ingore()` in the fluent config. And you won't be able to query those properties in LINQ queries. — David Browne - Microsoft, Nov 09 '18 at 15:38
@DavidBrowne-Microsoft doesn't EF automatically ignore read-only properties? — roozbeh S, Nov 09 '18 at 16:00

score 1 · Accepted Answer · answered Nov 09 '18 at 14:45

I'm not advocating a particular approach, just sharing information...

I wouldn't put your computation of FullName in a DTO. A DTO is just a simple object, really more of a struct, and shouldn't have any logic in it. The purpose of a DTO is to move data from one layer/tier to another and create a layer of indirection that allows your domain model to evolve independent of your clients. FullName on your Entity as a non-persistent property makes more sense here than in the DTO. If you want to go full enterprise, it would be in a transformer/adapter.

If your project is really small, and is likely never going to grow, then abandoning the DTO can be acceptable. Just keep in mind, that if your project grows you may have to do some refactoring, and there are some other things to consider...

Another benefit of the DTO is keeping some data where it needs to stay. For example, if you have sensitive data in your entity object and you don't put something in place to prevent it from being returned in a web request, you just leaked some information off your app server layer (think the password field in your user entity). A DTO requires you to think about what is being sent to/from the client and makes including data an explicitly intentional act vs an unintentional act. DTOs also make it easier to document what is really required for a client request.

That being said, each DTO is now code you have to write and maintain, which is the main reason to avoid them, and a model change can have a noticeable ripple effect through the system.

It comes down to deciding how you want to handle potential data leakage, how you want to manage your clients (if you can), and how complex your model may get.

Thanks for answer. My project is a winform so I guess there's no need to worry about data leakage. Am I right? — roozbeh S, Nov 11 '18 at 07:45
Likely not, unless you're sending/receiving data from out of process or off the client. — Jason Armstrong, Nov 11 '18 at 13:34

non-persistent properties in domain data model

1 Answers1