Instantiating Entities in Interactor

132 views
Skip to first unread message

Reed Law

unread,
Dec 19, 2013, 9:55:24 AM12/19/13
to clean-code...@googlegroups.com
My Interactors typically have 2 or 3 steps:
  1. Load up data from a Repository needed by this particular use case
  2. Instantiate entities that interact with the data and produce a set of results (optional)
  3. Save new data to the Repository

Step 2 is optional because sometimes a use case is a plain CRUD action that only needs to update the database. Other times I need the full blown object-oriented dance of the entities in order to get the result that is either presented directly in a view or saved to the database.

My question is, how should I clean up step 2? Some of the methods that instantiate entities are very long and I feel they need their own separate class. What would that class be called? I'm using Serializers for presenting data from Repositories to the views. I need something like a reverse serializer or de-marshaller.

Caio Fernando Bertoldi Paes de Andrade

unread,
Dec 19, 2013, 10:36:24 AM12/19/13
to clean-code...@googlegroups.com
You can use the Builder Pattern, and have a method in the Builder that builds an entity from a data structure. :)

Hope this helps,
Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

Jop van Raaij

unread,
Dec 20, 2013, 3:55:24 AM12/20/13
to clean-code...@googlegroups.com
I'd use a RepositoryGateway to translate data from the repository to entities and vice versa. Step 1 and 2 are therefore not in the interactor, but in the RepositoryGateway. The interactor can now concentrate on business logic only. Within the interactor, you only call repository.loadUser(id), returning a User entity and repository.saveUser(User). If the RepositoryGateway becomes too large, you could think about splitting the gateway by entity or some other logical rule.


On Thursday, December 19, 2013 4:36:24 PM UTC+1, Caio Fernando Bertoldi Paes de Andrade wrote:
You can use the Builder Pattern, and have a method in the Builder that builds an entity from a data structure. :)

Hope this helps,
Caio
On 19 Dec 2013, at 12:55, Reed Law <ree...@gmail.com> wrote:

My Interactors typically have 2 or 3 steps:
  1. Load up data from a Repository needed by this particular use case
  2. Instantiate entities that interact with the data and produce a set of results (optional)
  3. Save new data to the Repository

Step 2 is optional because sometimes a use case is a plain CRUD action that only needs to update the database. Other times I need the full blown object-oriented dance of the entities in order to get the result that is either presented directly in a view or saved to the database.

My question is, how should I clean up step 2? Some of the methods that instantiate entities are very long and I feel they need their own separate class. What would that class be called? I'm using Serializers for presenting data from Repositories to the views. I need something like a reverse serializer or de-marshaller.


--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

Andreas Schaefer

unread,
Dec 23, 2013, 3:58:27 PM12/23/13
to clean-code...@googlegroups.com
I agree with Jop. entity instanciation and persistance should not be done by interactors but by the gateway implementations.
Reply all
Reply to author
Forward
0 new messages