CSLA and deferred undo

KPrasadKhan posted on Monday, October 30, 2006

Hello,

I have been developing business applications for quite a long time. Most of which belong to either the banking industry or insurance industry. Since data security in these applications is of utmost importance, these applications tends to have a maker checker concept to ensure that there is a tight control in master setups. The schem works as follows.

• A record when enterd for the first time remains in invalid state.
• A user can modify it several times and yet the record remains in Invalid state.
• The checker inspects the data and accepts the changes. Only then the record becomes valid and is made available for use by other masters and or transactions.
• After a while (say 1 or 2 days, or a week or a month) the user decides to change some data in previously approved master. So he/she edits this record. This forces the record to become Invalid again. Yet the previously approved data remains available for use by rest of the system. The changes made to the data are not visible to rest of the system.
• The checker agains steps in and accepts the changes. This results in two things.
  • Changes being overlayed on to original data and made available to rest of the system.
  • An audit trail gets generated.

I am not sure whether this kind of requirement is satisfied by the CSLA framework and if yes how.

Regards,

Prasad P. Khandekar

Bayu replied on Monday, October 30, 2006

Hi,

The undo capabilities of CSLA or strictly intended for use within the application lifetime. So while users edit an object they can hit escape and 'undo' the edits and revert to the original values.

The framework does not inherently support undo after an object has been persisted to a DB (at leat not without modification/customization on your part).

However, giving it a short thought I think it wouldn't be too hard to implement:
- create 2 tables in you DB:
    - one with the yet unchecked modifications that still need to be approved
    - one with the approved changes
- the process of 'making' would create new entries in the former table
- the same holds true for modifications made to existing records, this would involve making a copy from the 'approved' table and then storing the modified version in the 'to approve' table
- the process of 'checking' would become a specific use-case where a record gets copied to from the former table to the latter

Disadvantages:
- duplicate table structure, thus duplicate maintenance
- specific persistency logic (CRUD operations get different interpretations then usual)

Advantages:
- clarity, the not-yet-approved items are isolated in a separate table
- the remainder of your relational model will only have relations to the 'approved' table

Alternative:
- add a boolean column which holds the 'checked' (true/false) value. In your CRUD operations you set the value accordingly. The key disadvantage here is that you can never ensure that unchecked records are NOT referenced in relations to other tables.

Regards,
Bayu