Unit of work and return of newly created object identifiers or custom response objects

Question

The unit of work is a great example, and I have included it in our CUD repository operations ...

The only thing I see as a drawback is the inability to return to the calling code the ID (or possibly the response of the DTO (s)) of several objects associated with the Unit of work when it comes to Create ().

For example, let's say I have a Customer and Order object. I create new transition objects in my code, add them via the .Create () method for the unit of work, and then complete the block of work.

Although my objects are correctly stored in the database, I do not call every Repository.Create () object from my consumer code, Unit of Work, so I have no way to send any information back to the consumption code related to each specific object.

Any ideas? Could it be (or better to ask the question, SHOULD) that the work module be expanded to return some type, maybe a user object, which may have object types with their new identifier in the dictionary, or something like that?

I just don’t know if these are suitable tasks for the Work Group. In the examples in books and blogs, I have not yet seen this problem.

Any thoughts?

Answer 1

A unit of work in itself does not preclude the return of identifiers or objects.

The problem may be that you are using work with too much granularity, i.e. create several objects whose identifier you might want to capture in one "block" (although in your example, returning an order object that has customerid will solve the problem). My recommendation would be to keep your units small, usually dealing with only 1 aggregate root.

Saying this, this is a real problem with the templates used with Command Query Responsibility Sharing (CQRS), such as Event Sourcing.

In this case, there are two approaches to solving the object ID: 1. Create a callback “the object is created” 2. give the pointer to the transition objects a guid id and use the Identity Mapper to get the created identifier.

Hope this helps

Stephen