Hi electrotype,
Chrriis, if I understand well, you would use entities like :
> ------------
>
> public class Person {
> long id;
> String name;
> String someOtherSimpleProperty;
> }
>
> public class Address {
> long id;
> String streetName;
> String someOtherSimpleProperty;
> }
>
If an address is bound to a person and retrieved passing Person objects,
then we could have the Person as a field of Address. A leaf can know its
parents if it is always retrieved through the parent.
This means that:
> public class PersonAddress {
> Person person;
> Address address;
> }
>
... may not be useful.
>
> So there is no "address" property directly in the Person entity...You
> actually have to retrieve the associated PersonAddress in a separate
> request. And all "associations of entities" are managed as standalone
> objects?
>
Yes. The idea is that there are so many objects and relations in the system
that it does not make sense to retrieve all of it. For example, the address
of a person is mostly useful on the person definition screen. Eventually we
ouptut that information in reports too. But persons are also of interest
for some contracts in which case addresses are not needed on those contract
screens, etc. We don't want to load a person, its contracts, addresses, and
all sorts of related objects, so each screen or area of the product
retrieves what it needs (with or without caching at the persistence layer).
> If a method needs to do some processing on a Person and needs to access
> some of its associated entities, it would have a signature like :
>
> ------------
> public void doSomeProcessingOnAPerson(Person person, PersonAddress
> personAddress, PersonJob personJob, Set<Person> personFriends, ...) {
> //...
> }
>
Well, yes, though generally the method that performs the processing is able
to retrieve associated data itself. So we do have such signatures:
> ------------
> public void doSomeProcessingOnAPerson(Person person) {
> //...
> }
>
where the call internally calls the person's address, job, etc. by
performing other calls. Generally, we pass data like in your first
signature when saving a modification to one of the associated objects.
In our product, we have a business layer that exposes all the above API.
Each call can internally call other business services. Business services
related to database stuff have a persistence layer for their data
retrieval. We have some caching at the business or persistence layer
depending on what makes sense.
I want to stress again that this is how it is done in our application, and
there might be other ways/patterns better suited at your use cases.
-Christopher
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
