I'm new in this platform. And when I started modeling some databases I've asked myself: "Why use a Exposed read only entities?". I've only asked that because when the propertie "expose read only" is setted to "No" the use of the data is faster than when we use it as "Yes". So, why use it at all?

But It's called a best-practice. Why?

I've searched the platform and I hadn't found  the answer.

Thank you for the info.

Solution

Hi Lucas,

This is the best-pratice because you can create business roles do create registers in the entity in an one place like a Server Action, for example.

Some benefits:

1) Improve maintability and prevents that the entity is manipulated in a wrong way, because the logic is in the one place

2) The business logic is the same for all other applications mobile, micro-service and etc.

Solution

Hi Lucas,

Don't know about "using data being faster" if the data is exposed as read only. In fact, I don't think there is any difference.

It is a best practice in terms of maintenance.

An entity may be accessed by many different modules, or even applications. 

If you allows all of those places to write data to the entity, any validation required to the data that is forgot by the developer will cause problems.

When you expose read only and create wrappers for the entity (to write data), you guarantee that everybody has to do it using this channel. Much easier to keep track and prevent issues.

Justin James has some nice articles about Entity Wrappers. 

https://medium.com/@jmjames/outsystems-crud-wrapper-basics-e9a577a3e044

https://medium.com/@jmjames/outsystems-crud-wrapper-checklist-c7efb2ad9115

Hope this helps.

Cheers.

Leandro Correa wrote:

Hi Lucas,

This is the best-pratice because you can create business roles do create registers in the entity in an one place like a Server Action, for example.

Some benefits:

1) Improve maintability and prevents that the entity is manipulated in a wrong way, because the logic is in the one place

2) The business logic is the same for all other applications mobile, micro-service and etc.


Thank you for the info!

Eduardo Jauch wrote:

Hi Lucas,

Don't know about "using data being faster" if the data is exposed as read only. In fact, I don't think there is any difference.

It is a best practice in terms of maintenance.

An entity may be accessed by many different modules, or even applications. 

If you allows all of those places to write data to the entity, any validation required to the data that is forgot by the developer will cause problems.

When you expose read only and create wrappers for the entity (to write data), you guarantee that everybody has to do it using this channel. Much easier to keep track and prevent issues.

Justin James has some nice articles about Entity Wrappers. 

https://medium.com/@jmjames/outsystems-crud-wrapper-basics-e9a577a3e044

https://medium.com/@jmjames/outsystems-crud-wrapper-checklist-c7efb2ad9115

Hope this helps.

Cheers.

Thanks for the info and for the links. Justin James has a new fan.


I appreciate the benefits of having CRUD wrappers but there are certain important drawbacks using them:

If I have a data model with 100 entities the last thing I want to do is to have to create CRUD wrappers for each entity. OutSystems is about Rapid Application Development and there`s nothing rapid about having to create wrappers for each entity!

It breaks certain scaffolding patterns. For example when you drag the same entity twice in a workflow, OutSystems creates a fully functioning CRUD application. If the underlying entity is set to read-only, the scaffolding doesn`t work since it cannot use the Entity Action to create the entity. It knows nothing that you have prepared a CRUD wrapper instead. But part of the power of OutSystems is its scaffolding capabilities! A tedious workaround would be to leave the entity to its default setting Read-Only:No, do the scaffolding pattern, then replace the Entity Action to create the entity with your CRUD wrapper and then go back to the Core module to set the Read-Only setting to Yes. And of course refresh the references to your entity if you are using the 4-layer architecture that you should!

If you add your validations in the CRUD some developers may not bother implementing them in web screen or server actions since they will assume that CRUD wrappers will handle everything. They may also assume that the CRUD wrapper will handle any business particular validations which may not be the case if that entity is used across different applications with different business requirements. Some forum members advocate that you can place business rules in CRUD wrappers. But isn`t this breaking the 4 layer canvas architecture? Shouldn`t CRUD wrappers be in the Core layer which is business agnostic?

Just to be clear, I`m not saying not to use CRUD wrappers but there may be scenarios that doing so doesn`t make a lot of sense. For example if you want to build a demo system or a really small application with a well defined scope, or there`s no requirement for creating audit trails, logs or any cascade delete logic for example.

Dimitrios Bessas wrote:

I appreciate the benefits of having CRUD wrappers but there are certain important drawbacks using them:

If I have a data model with 100 entities the last thing I want to do is to have to create CRUD wrappers for each entity. OutSystems is about Rapid Application Development and there`s nothing rapid about having to create wrappers for each entity!

This is true. That's why we are lobbying to OutSystems to allow the creation of wrappers automatically, and we change those that need to be changed. But this does not seem to be top priority.


It breaks certain scaffolding patterns. For example when you drag the same entity twice in a workflow, OutSystems creates a fully functioning CRUD application. If the underlying entity is set to read-only, the scaffolding doesn`t work since it cannot use the Entity Action to create the entity. It knows nothing that you have prepared a CRUD wrapper instead. But part of the power of OutSystems is its scaffolding capabilities! A tedious workaround would be to leave the entity to its default setting Read-Only:No, do the scaffolding pattern, then replace the Entity Action to create the entity with your CRUD wrapper and then go back to the Core module to set the Read-Only setting to Yes. And of course refresh the references to your entity if you are using the 4-layer architecture that you should!

Again, this is true. And the automatic wrappers should work with the scaffolding patterns too (there are ideas for that as well).


If you add your validations in the CRUD some developers may not bother implementing them in web screen or server actions since they will assume that CRUD wrappers will handle everything. They may also assume that the CRUD wrapper will handle any business particular validations which may not be the case if that entity is used across different applications with different business requirements. Some forum members advocate that you can place business rules in CRUD wrappers. But isn`t this breaking the 4 layer canvas architecture? Shouldn`t CRUD wrappers be in the Core layer which is business agnostic?

This is not correct. The Core Layer in the 4LC is not business agnostic. It is aware of the business and is the place to put everything that is business-related but generic enough to be used in different places.

Just to be clear, I`m not saying not to use CRUD wrappers but there may be scenarios that doing so doesn`t make a lot of sense. For example if you want to build a demo system or a really small application with a well defined scope, or there`s no requirement for creating audit trails, logs or any cascade delete logic for example.

Indeed, it makes more sense on medium to large applications.

Cheers