Home/ Questions/Q 451863
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T22:00:56+00:00

I have a classic 3-tier ASP.Net 3.5 web application with forms that display business

  • 0

I have a classic 3-tier ASP.Net 3.5 web application with forms that display business objects and allow them to be edited. Controls on the form correspond to a property of the underlying business object. The user will have read/write, readonly, or no access to the various controls depending on his/her role. Very conventional stuff.

My question is: what is the object-oriented best practice for coding this? Is there anything more elegant than wrapping each control in a test for the user’s role and setting its Visible and Enabled properties?

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To work properly, I have found that access levels should be in this increasing order:
    NONE, VIEW, REQUIRED, EDIT.

    Note that REQUIRED is NOT the top level as you may think it would be since EDIT (both populate & de-populate permission) is a greater privilege than REQUIRED (populate-only permission).

    The enum would look like this:

    /** NO permissions.
 *     Presentation: "hidden"
 *     Database: "no access"
 */
NONE(0),

/** VIEW permissions.
 *     Presentation: "read-only"
 *     Database: "read access"
 */
VIEW(1),

/** VIEW and POPULATE permissions.
 *     Presentation: "required/highlighted"
 *     Database: "non-null"
 */
REQUIRED(2),

/** VIEW, POPULATE, and DEPOPULATE permissions.
 *     Presentation: "editable"
 *     Database: "nullable"
 */
EDIT(3);

    From the bottom layer (database constraints), create a map of fields-to-access. This map then gets updated (further restrained) at the next layer up (business rules + user permissions). Finally, the top layer (presentation rules) can then further restrain the map again if desired.

    Important: The map must be wrapped so that it only allows access to be decreased with any subsequent update. Updates which attempt to increase access should just be ignored without triggering any error. This is because it should act like a voting system on what the access should look like. In essence, the subsequent layering of access levels as mentioned above can happen in any order since it will result in an access-level low-water-mark for each field once all layers have voted.

    Ramifications:

    1) The presentation layer CAN hide a field (set access to NONE) for a database-specified read-only (VIEW) field.

    2) The presentation layer CANNOT display a field when the business rules say that the user does not have at least VIEW access.

    3) The presentation layer CANNOT move a field’s access up to “editable” (nullable) if the database says it’s only “required” (non-nullable).

    Note: The presentation layer should be made (custom display tags) to render the fields by reading the access map without the need for any “if” statements.

    The same access map that is used for setting up the display can also be using during the submit validations. A generic validator can be written to read any form and its access map to ensure that all the rules have been followed.

    • 0