You are not logged in.
Pages: 1
Hello
I am a beginner in using the framework, studying the use of Mormot (DDD) on my system ...
I wonder how can I use SQLRecord ID field in the DTO objects,
I know that the ID field is an implementation detail, but I need this information in the DTO ...
If anyone can help me, this I thank you ....
Offline
You can define the DTO as you wish.
Including an ID within the field, without any problem.
Are you not making a confusion between DTO and Aggregate?
The TSQLRecord(s) are gathered within one Aggregate Root, which would be exposed using DTO objects from SOA services.
Are you talking about TDDDRepositoryRestFactory auto-mapping?
In this case, the current implementation ignore the ID in the mapped aggregate.
It is on purpose.
The ID is to be retrieved outside the aggregate properties, e.g. via the TDDDRepositoryRestQuery.CurrentORMInstance property.
Then you can create your DTO gathering both the TSynPeristent aggregate and CurrentORMInstance.ID.
Offline
The ID is to be retrieved outside the aggregate properties, e.g. via the TDDDRepositoryRestQuery.CurrentORMInstance property.
Then you can create your DTO gathering both the TSynPeristent aggregate and CurrentORMInstance.ID.
can be more about it?
Offline
You could transmit the ID as a value outside the aggregate object itself.
The ID won't be part of the aggregate object properties, but transmitted as a separated "out" parameter of the DDD service.
Then you could use this ID to make a reference to the aggregate.
Most of the time, you could use a real-world identifier for the aggregate.
Like a serial number, a client code, a logon name, an account number, an invoice reference or an ISBN.
It is always preferred to use one unique identifier which does exist in the real world, than exposing your "computer specific" ID.
Most of the time, if you need to store an ID, your DDD model is probably broken.
Offline
Most of the time, you could use a real-world identifier for the aggregate.
Like a serial number, a client code, a logon name, an account number, an invoice reference or an ISBN.
I fully agree, but sometimes there is a need to get our "computer specific" ID. But still we try to follow these recommendations.
I take this opportunity to thank you for a wonderful framework.
Offline
Pages: 1