public class Address {
@NotEmpty @Max(50)
private String street1;
@Max(50)
private String street2;
@Max(9) @NotNull
private String zipcode;
...
}and then be able to say something like:
public class Order {
@Valid @NotNull private Address delivery;
}The implications of something like this go beyond mere validation. IMHO it si an elegant solution that if built properly will improve the DRYness of the code across all layers of any java application.
This is the intention behind jsr-303. .
2 comments:
It is nice until 3 months after roll-out a business rule change means a field is no longer mandatory. Now something that used to be a 30 second configuration update requires a recompilation, with subsequent staging of your war file through dev, QA and production environments.
Not every business rule change can be done in a 30 seconds configuration change. I'll argue that even if the change is at the configuration level you'll have to stage your war/jar/whatever through dev, QA and production as there may be logic depending on something been required; you know, a missing if (foo == null) here and there. I do think that this, like every other technology/framework out there, is not the silver bullet solution to validation but, used appropriately it can go a long way DRYing the code.
Post a Comment