C# Architecture Question

Question

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?

Answer 1

I think you are on the money.

Answer 2

Yeah, you should cancel the entire process in either case. You are calling accept on the root of the object graph, so the expectation of the consumer is going to be that the entire graph is persisted. I would treat this as an all or nothing situation.

Answer 3

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.

Answer 4

If say adding students to your class modifies the state of class only (like if you are storing which student are in class in separate table, number of more students class can have etc.) then you don't need to persist the student object altogether.

If adding to this class or removing from this class modifies the student class (like number of more classes they can take etc.) then you should propagate the cancel to student objects also.

Answer 5

Hey everyone, thanks for confirming my take on this. It helps to have a sounding board for a project, and since I dont have one at work this site in invaluable for me in that respect.

Keith, I like your idea of the cancel state, but I think that is more overhead than I am prepared to deal with at the moment. I may add it in a later iteration. But to answer your question about what can be done with the cancel its a bit different than what you are interpreting it as. I wanted to be able to reuse these DomainObjects in later unrelated projects but I didnt want to DomainObjects to dictate the method or persistance or validation, which is why I chose the delegate/event route for updating. My theory is that when I decide to use a DomainObject in an application, I can subscribe to the event in my custom code which will do the validation and persistance. If I decide to cancel, then my client code can at that point determine what the next step is to resolve the condition that caused me to cancel in the first place. Make sense?