I'm debating how to handle business rules related to the "Status" of a purchase order object (a CSLA-based object).
Some of the business rules will be flow control - which status transitions are allowed and which are not. Other business rules will focus which properties can be changed or which activities can be performed based on the current status.
I'm trying to decide between two different ways of handling this:
a.) using child objects that follow the "State Design Pattern".
b.) using WF (state machine).
Anybody have any thoughts on the advantages/disadvantages of these two approaches?
xxxJasonxxx:
...I'm trying to decide between two different ways of handling this:
a.) using child objects that follow the "State Design Pattern".
b.) using WF (state machine).
Having been severely bitten by Microsoft at least once in the past by basing a significant aspect of our application on their "latest and greatest" technology, I'd tend to recommend a layered approach that insulates you to some degree from technology changes.
So, I'd opt for (a).
We have several use cases in our application where the set of available "next states" and what property changes are allowed for the current state are easily constrained by simple CSLA validation rules.
Copyright (c) Marimer LLC