CODEWITHSUNDEEP
c#entitydomain-driven-designrepository-patternddd-repositories
Vahid
Vahid

Reputation: 5444

How to set Id of Entity object when getting it from Repository

In Domain-Driven Design, how can I hydrate the Id property when I retrieve an entity from a repository? When I create an entity for the first time (before it is persisted), I can generate a unique ID in the entity's constructor. But when I retrieve an entity from the repository, it already has an ID. How do I set the Id property in this case? Passing the ID to the entity's constructor doesn't feel right to me, but maybe it is the correct approach?

I am not using an object-relational mapping (ORM) tool.

public interface IPersonRepository
{
    Person GetById(long id);
}

public abstract class Entity
{
   public long Id { get; private set; }

   protected Entity()
   {
      Id = // Generate a unique Id with some algorithm.
   }
}

public sealed class Person : Entity
{
   //...
}

Upvotes: 0

Views: 2000

Answers (2)

Maxim Kitsenko
Maxim Kitsenko

Reputation: 2333

1) Aggregate or Entity? I think there is some confusion in your question in terms of DDD. In general you shouldn't load entities. You should load Aggregate, through Aggregate root (which is entity), all other entities for this aggregate should be loaded automatically.

From Evans DDD:

only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.

Martin Fowler:

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates.

Aggregate Root

2) How to set a Id. It's a good idea to use immutable properties. public long Id { get; private set; }, lets think we are doing things correctly when we use immutable id. Now lets go ahead and found possible ways for setting Id properly.

  1. set id from the class method. Looks confusing to set id for existing entity (aggregate root). I don't suggest to use this option.

  2. set id from constructor. Why not? You set the Id during the creation of the entity (aggregate root). From Evans DDD:

    A public constructor must follow the same rules as a FACTORY: It must be an atomic operation that satisfies all invariants of the created object.

  3. factory. From Evans DDD:

    Complex assemblies, especially of AGGREGATES, call for FACTORIES

  4. set id during deserialisation. Is clear and simple way. I would chose this one. I would store Id and other data together (it's common practise). GetById(long id); returns Person which already had Id setted during deserialisation.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57214

When I CREATE the Entity for the first time (before its persistence), I can generate a unique id in Entity's constructor...

which may not be a good idea. Non deterministic data (like time, or copies of remote mutable state) should be inputs to your domain model. In practice, you will often get away with it; but that alone doesn't make it a good idea.

The usual answer is that the repository will fetch the persisted representation of the information (a DTO, for example), and hand that off to a factory whose purpose is the construction of the entity.

So the identity of the entity becomes just another piece of information passed from the repository to the factory.

Now, "factory" here is just another life cycle pattern; and it can take many different forms, including the form of constructor. In which case, the identifier would normally just be passed into the entity as an argument.

Identifiers in particular can be a bit weird, because they don't normally express business semantics. It's typical of the identifier pattern that they are opaque things that really only support equality comparison. Your entities almost never look at their own identifier to figure out what to do next.

But if your entity needs a reference to its own identifier, for whatever reason, you'll normally create that reference when you initialize the object, and leave it unchanged from that point forward (in other words, the entities identifier property is an immutable reference to an immutable value).

Upvotes: 1

Related Questions