 |
 |
 |
Modeling: User's Guide |  |
 |
|
|
|
|
Modeling: User's Guide | |
|
|
Sometimes you need more than a simple EditingContext. Suppose you have an application where a complex operation needs several steps to be performed by the user, each of these steps implying the insertion, deletion or updates of many objects. This complex operation can be a sub-process of an other long-standing process.
Normally you want to give to the user the possibility to cancel the modifications at any point in the sub-process. Most of the time, you also want all the changes made during these steps to be applied as a whole, or not at all-this is Atomicity. How can this be done?
One possibility could be to use an other EditingContext. It might be suitable for very simple cases, however you probably do not want this, because:
An other solution could be to track all the changes made during the successive steps. However, this is a difficult task. Each step will probably trigger one or more methods transforming the objects; these methods probably trigger other methods, etc. It will be difficult to track the changes, and it will be even more difficult to revert them.
In such a situation, you will not be able to separately validate the changes from the complex operation: validation would have to apply to all changes, those made by the subprocess along with those previously made by the main process. Hence you have no way of separately checking the Consistency of the changes made in the sub-process itself.
Last, if your application maintains some other view based on the main EditingContext, you probably also do not want that the changes made in the sub-process are visible in the other views before the user validates (or discards) them. But insuring Isolation will be a real pain at best, impossible at worst.
|
|
|
Modeling: User's Guide | |
|
|