I am considering the visitor for its intrinsic ability to add behavior to a set of classes without opening (editing) this classes. In this case, the behvaior is cross-domain validation and the classes are the domain model. I like declarative validation on domain entities, but there are situations where the is not sufficient and the validity of a domain object depends on the state of another and can also vary based on some context in the Application. Here is a requirement from my current project which is a financial application.
A client has a Portfolio which can have a 1 or more investments. Each investment has an allocation amount ($) or % (They all must be the same). If the allocations are in $, the must add up to the total investment size, otherwise it must add up to 100%. So here are some of the validation needed
1) Each investment must have an allocation
2) If first investment allocation is a $ all remaining investments must be in $ (can't miz $ and %)
3) if investment allocations are in $, they must sum up to the total investment size of the portfolio,
otherwise they must add up to 1 (100%)
4) Application can be configured such that constraint 3 is not required. In this mode, if the constraint
is not satisfied, the app adds an additinal CASH investment for the remainig allocation.
#1 can use simple declarative (Required) validator.
#2 depeonds on the Portfolio determing the expected allocation type ($ or %) and then summing all investment allocations. I don't think this can be done declaritively so do I just override the Portfolio.IsValid to perform declarative steps and then check this validation rule.
#3 Depends on the application context. The portfolio does not have this information and thus cannot perform the validation. I would construct a visitor with the App context and then visit the entire domain model.
On 6/16/06, hammett <[EMAIL PROTECTED]> wrote:
I just think that the visitor pattern is applied when you have
distinct classes that need to be traversed but you need to act
different depending on the type of the class, well, being visited.
The way you explained, seems that you only have Domain classes, and
domain class is unlikely to have these variations. So seems that you
only need to propagate a validation message, like:
object -> Validate
validate this:
validate my members
validate my collections
This is not something I'd use visitors for.
Doesn't ActiveRecord use visitors in this context?
Anyway, I probably didn't understand it well and I'm just rambling
about an hypothetical design.
On 6/16/06, Craig Neuwirt <[EMAIL PROTECTED]> wrote:
> My goal is to perform validation as simple as possible given validation
> specific to a model as well as cross-domain validation.
--
Cheers,
hammett
http://hammett.castleproject.org/
_______________________________________________
CastleProject-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/castleproject-users
_______________________________________________ CastleProject-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/castleproject-users
