Relationship between aggregates and actions

Jessica Marques

Solved

Question

I am studying the aggregates in OutSystems and after discussing some points here on the forum and reading the documentation, I developed this statement about the relationship between the aggregates and the actions (preparation, screen action and server action). Can you confirm that it is correct, or if I made a mistake?

The preparations are the ones that use the aggregates the most, considering that they get the data from the database to execute the screen, for example. Screen Actions depend on the user's interaction with the screen, through links or buttons, for example, they can use aggregates to work with data in these situations. And finally, server actions, in order to encapsulate logic, can also use aggregate, to have an optimized search for data, but for that, it is necessary to pass the result to the destination where you want to use the data type as entities or create a specific structure.

Best regard,

Jessica Marques.

09 Mar 2020

Kilian Hekhuis

MVP

Solution

Hi Jessica,

I'm not sure I understand the point. There is no "relationship between Aggregates and Actions", other than that Aggregates, in Traditional Web Apps, always reside inside an Action (not that for Mobile and Reactive Web, Aggregates can also live at the Screen level). But that's also true for other logic.

"The preparations are the ones that use the aggregates the most" - though Preperations typically contain Aggregates, I'm not sure whether they "use the Aggregates the most". Screen Actions and Server Actions can use Aggregates just as well.
"Screen Actions depend on the user's interaction with the screen, through links or buttons, for example, they can use aggregates to work with data in these situations." - true, but overly precise - Screen Actions contain logic that is triggered when users interact with the Screen, and that logic may contain Aggregates (or refresh them).
"server actions, in order to encapsulate logic, can also use aggregate, to have an optimized search for data, but for that, it is necessary to pass the result to the destination where you want to use the data type as entities or create a specific structure." - not sure what you mean by "optimized search". And again, Server Actions just contain logic, of which Aggregates can be a part. And I wouldn't say it's necessary to "pass the result" in order to search for data, you could for example execute a query just to check whether the Action's Input is valid (e.g. whether a user exists, or whether they have access to the data), and return something not related to the query.

So, summing up, what you wrote is kind of true, but it's a bit of a jumble of things that are true by themselves, but don't necessarily form a coherent or exhaustive description.

See solution in context

09 Mar 2020

1 reply

09 Mar 2020

Show thread

Hide thread

Jessica Marques

Kilian Hekhuis wrote:

Hi Jessica,

"The preparations are the ones that use the aggregates the most" - though Preperations typically contain Aggregates, I'm not sure whether they "use the Aggregates the most". Screen Actions and Server Actions can use Aggregates just as well.
"Screen Actions depend on the user's interaction with the screen, through links or buttons, for example, they can use aggregates to work with data in these situations." - true, but overly precise - Screen Actions contain logic that is triggered when users interact with the Screen, and that logic may contain Aggregates (or refresh them).
"server actions, in order to encapsulate logic, can also use aggregate, to have an optimized search for data, but for that, it is necessary to pass the result to the destination where you want to use the data type as entities or create a specific structure." - not sure what you mean by "optimized search". And again, Server Actions just contain logic, of which Aggregates can be a part. And I wouldn't say it's necessary to "pass the result" in order to search for data, you could for example execute a query just to check whether the Action's Input is valid (e.g. whether a user exists, or whether they have access to the data), and return something not related to the query.

So, summing up, what you wrote is kind of true, but it's a bit of a jumble of things that are true by themselves, but don't necessarily form a coherent or exhaustive description.

Hi Kilian Hekhuis,

I was probably not very clear in the title: "relationship between Aggregates and Shares", what I would really like to know was exactly how the aggregates were present in the actions.
Thank you very much for your notes and explanations, I realized that I was wrong on some points.

Best regard,

Jessica Marques.

09 Mar 2020

Pedro Vila Nova

Hello Jessica,

It's something like that.

You can also, search about Client Actions and Service Actions. =)

Best regards,

PVN

09 Mar 2020

Kilian Hekhuis

MVP

Solution

Hi Jessica,

"The preparations are the ones that use the aggregates the most" - though Preperations typically contain Aggregates, I'm not sure whether they "use the Aggregates the most". Screen Actions and Server Actions can use Aggregates just as well.
"Screen Actions depend on the user's interaction with the screen, through links or buttons, for example, they can use aggregates to work with data in these situations." - true, but overly precise - Screen Actions contain logic that is triggered when users interact with the Screen, and that logic may contain Aggregates (or refresh them).
"server actions, in order to encapsulate logic, can also use aggregate, to have an optimized search for data, but for that, it is necessary to pass the result to the destination where you want to use the data type as entities or create a specific structure." - not sure what you mean by "optimized search". And again, Server Actions just contain logic, of which Aggregates can be a part. And I wouldn't say it's necessary to "pass the result" in order to search for data, you could for example execute a query just to check whether the Action's Input is valid (e.g. whether a user exists, or whether they have access to the data), and return something not related to the query.

So, summing up, what you wrote is kind of true, but it's a bit of a jumble of things that are true by themselves, but don't necessarily form a coherent or exhaustive description.

09 Mar 2020

1 reply

09 Mar 2020

Show thread

Hide thread

Jessica Marques

Kilian Hekhuis wrote:

Hi Jessica,

"The preparations are the ones that use the aggregates the most" - though Preperations typically contain Aggregates, I'm not sure whether they "use the Aggregates the most". Screen Actions and Server Actions can use Aggregates just as well.
"Screen Actions depend on the user's interaction with the screen, through links or buttons, for example, they can use aggregates to work with data in these situations." - true, but overly precise - Screen Actions contain logic that is triggered when users interact with the Screen, and that logic may contain Aggregates (or refresh them).
"server actions, in order to encapsulate logic, can also use aggregate, to have an optimized search for data, but for that, it is necessary to pass the result to the destination where you want to use the data type as entities or create a specific structure." - not sure what you mean by "optimized search". And again, Server Actions just contain logic, of which Aggregates can be a part. And I wouldn't say it's necessary to "pass the result" in order to search for data, you could for example execute a query just to check whether the Action's Input is valid (e.g. whether a user exists, or whether they have access to the data), and return something not related to the query.

So, summing up, what you wrote is kind of true, but it's a bit of a jumble of things that are true by themselves, but don't necessarily form a coherent or exhaustive description.

Hi Kilian Hekhuis,

Best regard,

Jessica Marques.

09 Mar 2020

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.

See the full guidelines