4 Layer Canvas - Security of Core Layer Entities

4 Layer Canvas - Security of Core Layer Entities

  

Hi,

I am working on a huge application which would end up having 30+ e-spaces collectively for all layers. Per 4 Layer Canvas Architecture, I know that entities specific to End User layer modules would reside in respective modules and those business entities which are common to more than one end user modules would reside in e-spaces which are at Core layer.

Therefore for entities which are in End User Layer modules I can keep their "Public" property as "No" and "Expose Read Only" as "No". However for entities which are in Core Layer e-spaces, there are two options:

1. If "Expose Read Only" is set to "No" and "Public" set to "Yes", the referencing modules would be able to perform any write operation on those entities, but this would compromise the security of data in those entities as any other application modules on the same server would also be able to reference them and perform write operations. But with this approach, the developers would be able implement their logic in respective End User layer modules to write/update data in core entities and would also be able to debug code easily.

2. If "Expose Read Only" is set to "Yes" and "Public" set to "Yes", the referencing modules would be able to reference Core layer entities but won't be able to perform any write/update operation directly in End User layer modules. To perform write/update generic server actions would have to be developed but it would be very tedious and complicated task keeping in mind the complexity of application. And if there are no generic server actions developers would end up implementing several server actions on Core layer to accomplish their tasks which is not what we want. Also, this would make code debugging a bit difficult for developers as they would have to switch between modules.

I can go with mix of two approaches but there would be very few entities (hardly 4-5%) where I can use the second approach.

Please suggest best design approach in this kind of situation.

Solution

Hi Junaid,

The second option is what we always use: have CRUD actions in our Data layer for every read-only Entity (usually a single "EntitySave" that doubles for CreateEntity + CreateAndUpdateEntity). Depending on what kind of data we write, we might put a "combined" save Action in the Core Services layer that saves multiple related Entities at once, or have a Save action in the Core Services (or, depending on the type) Business Logic layer that does some further checking for valid combination of values etc.


Solution