Michael Hunger wrote: > You can still model the types you want in Java even integers restricted > to a range. I'd rather prefer concrete types for concrete business > values, where you have: > * validation > * formatting > * hints > * factory methods > * other business methods with business value > > even on small types like an ISBN or ILN or ZIP code. > > So perhaps abstaining from primitive types in your entities at all would > be a possible solutions.
Yeah, this is similar to what Stephan wrote about here: http://stephan.reposita.org/archives/2008/05/02/never-never-never-use-string-in-java-or-at-least-less-often/ Which I generally agree with, and the main concern is (I think) how to be able to do it with as little effort as possible and getting the most benefit out of it. > Regarding validation: > we once wrote a bean based ui-framework that validated state of a java > bean in 4 phases where all the attributes where evaluated within a phase > (and all error reported that failed not just the first) and only if the > phase completed the next phase was run. > > The phases were: > 1) syntax check (i.e. input formats) > 2) mandatory checks (not null) > 3) property check (business validation per property) > 4) entity checks for depenedend property for the whole entity or even > encompassing related entities > > we used an reflection based mechanism to provide the validation code per > property or bean having the property name in the method name and giving > enough context needed for the validation. Sounds reasonable. Constraints in Qi4j can be used for 1-2, and some of 3, and should explicitly NOT be used for 4. > what is very important is that the validation rules are mostly not > static but depend on the state of the entity, so if you have an order in > a certain state it has different validation rules than in a previous or > latter state. switching the validation or having dynamic state dependend > mixins dealing with this validation is the key so the Validatable stuff > seems to me more important than the constraints as these would be > handled by the concrete types themselves. Right. In Qi4j we have the Validatable interface that could be used, and I think finding good patterns for that is a good start. With regard to non-static validation rules this could be achieved either by having the Validatable implementation delegate to something else, which can change, or doing something as bizarre as using casts to get the right "set" of rules for the moment. This last one is something that needs to be explored to find out whether it's useful or not. Basically, an EntityComposite can be cast to another EntityComposite type if the latter is a subtype of the first. This can be used to extend the mixins and properties of the Entity, but can also be used to replace implementations of existing mixin types in the EntityComposite. If this is a good way to change validation rules or not I am not sure yet, but it's a possibility. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
