Home/ Questions/Q 224051
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T19:16:49+00:00

I am designing a project where all the main components share a single common

  • 0

I am designing a project where all the main components share a single common DomainObject (yeah I stole the term from O/RM world, but its not quite an O/RM project.) The DomainObject maintains the objects change state (dirty/clean) and allows itself to be rolled back or committed (AcceptChanges(), RejectChanges() ). When AcceptChanges() is called on an object, it fires an event and that event would trigger the writing of hte values to the underlying datastore. Also, it passes a parameter allowing the persistance to be cancelled in the event.

1) Classroom (a DomainObject) is instantiated and its properties modified.
2) Classroom.AcceptChanges() is called, triggering the OnAcceptEvent and passing the DomainObjectChangeEventArgs, which contain a boolean property called Cancel
3) If Not Cancelled by the event, changes are accepted and the state of hte Classroom is updated.
4) The project then calls AcceptChanges on any internal properties that are also DomainObjects, such as Student.
5) Each Student triggers the OnAcceptEvent passing a DomainObjectChangeEventArgs…etc.

Now, asking the community at large:

A) Would you have the cancel indicator on the Classroom’s AcceptEvent stop the entire process forcing it to no longer evaluate and possibly Accept any Students, or would you code the Cancel to just apply to the classroom.
b) Would the Cancel indicator on any Student be expected to stop the processing on any additional Students?

My initial thought is that the cancel indicator on the Classroom’s event should stop the entire process, therefore allowing a graceful preservation of the pre-accepted state of the classroom and all the students without involving the overhead of a transaction. But I am not necessarilly convinced that I am correct.

What would you do?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’d call the event CanSave, which returns an enum { OK, Cancel }. Prior to persisting anything I’d query the whole object graph, looking for a cancel. Each object can validate itself and cancel if it’s not currently in a persistable state… averting most, but by no means all, rollbacks.

    But what can you do with a Cancel? One of the prime edicts of good software is “Allways allow the user to save there work”. Programmers wouldn’t abide an IDE which won’t save uncompilable source-code, so why would you expect your users to put-up with it?

    Cancel states should be truly exceptional states… like can’t write to readonly file –> “Save As” instead? Or a null key-field –> “username is required”.

    So what’s the alternative? Save to an intermediate format, one which can store “invalid” data… like a text file.

    Aside: I’ve often thought that database-apps are missing a “validate” button, allowing the user to find out “is this OK?” without actually committing to it.

    Just food for thought.

    Cheers. Keith.

    • 0