title: C# Architecture Question
body: <p>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 <em>quite</em> 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.</p>
  
  <blockquote>
    <p>1) Classroom (a DomainObject) is instantiated and its properties modified. <br>
    2) Classroom.AcceptChanges() is called, triggering the OnAcceptEvent and passing the DomainObjectChangeEventArgs, which contain a boolean property called Cancel<br>
    3) If Not Cancelled by the event, changes are accepted and the state of hte Classroom is updated.<br>
    4) The project then calls AcceptChanges on any internal properties that are also DomainObjects, such as Student. <br>
    5) Each Student triggers the OnAcceptEvent passing a DomainObjectChangeEventArgs...etc.<br></p>
  </blockquote>
  
  <p>Now, asking the community at large:</p>
  
  <p>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?</p>
  
  <p>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. </p>
  
  <p>What would you do?</p>