The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

curtyr (1) [Avatar] Offline
What is the best way to perform validation in POJOs?

For example, in Chapter 3, an example implementation of updateDeliverInfo is provided. This returns true or false as an indication of success/failure. However, it does not indicate the actual specific reason for the failure.

So, I guess we could use a return code (especially as exceptions are not encouraged for this sort of validation)? However, what if there is more than one failure? For example, both the deliveryAddress and deliveryTime are wrong (for whatever reason). The UI would want to know both of these problems at the same time.

How should simple things like maximum field length, mandatory fields and invalid values be handled? Ideally, you don't want these sorts of things creeping out into the UI - but is this unavoidable? Should we expose things like max length as properties of the POJO, so that at least the max length value is only in the POJO (and we only have to change it once).

What is the best way to ensure that an object graph as a whole is valid and that it can't be persisted until it is in a valid state?

There are a lot of questions here, but there seems to be very little advise, patterns, etc. on what I would see as fundamental to enforcing business rules in the POJO (for which advocates claim they are so good for).

Any thoughts?
ceracm (110) [Avatar] Offline
Re: POJO Validation
You ask some very interesting questions. Questions that deserve a much longer answer than can fit into a forum post. But here are a few quick thoughts.

With regards to how the business tier reports errors to the presentation tier. As you point out , if you need to return the business tier must sometimes return multiple errors. One option is Martin Fowler's Notifier pattern ( The business tier returns a collection of errors to the presentation tier.

How to do validation can be a challenging issue. It often needs to be done in as many as three separate places: in the business tier, in the server-side presentation tier and in client-side JavaScript. Ideally, you want to specify validation information such as the size/format of fields only once. However, I think many successful applications have duplicated this information without a problem so its not the end of the world if you do that. Also, sometimes the needs of the presentation tier are sometimes different than the needs of the domain model. e.g. perhaps in the domain model a phone number is a 10 digit number but in the presentation tier it could include dashes and digits. Internationalization is another issue where external formats can be different for different users.

The Hibernate Validator is an interesting annotation-based approach ( that solves some validation problems. HIbernate can check the constraints before saving an object. The application can also check them. The Seam web framework ( does this automatically.

With regards to validating an object graph. One option is for the domain object's business methods to ensure that it is always valid. Another option is for the business tier to validate it prior to it being saved. You might also be ale to use a Hibernate Event Listener to perform the check.

Another source of information about this topic is the domain driven design mailing list ( The archives contain discussions about validation.

Regarding updateDeliveryInfo() in chapter 3. It returns false if the delivery address/time are invalid. ie. for that combination of delivery address/time there is no restaurant. To figure out whether the delivery address is invalid regardless of the time and/or whether the time is invalid regardless of the address would require some additional queries. This could be done in inside the PendingOrder or PlaceOrderService. Or perhaps it should be done in the PlaceOrderFacade in order to simplify the domain model classes. Just a thought....In either case a Notification containing the collection of errors would ultimately be returned to the presentation tier.

I hope this helps.

Enterprise Java consulting and training -
Author, POJOs in Action -
Enterprise POJOs blog -