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. (2) [Avatar] Offline

My question is somewhat related to this earlier post:, but I got still some questions.

Let's say I got an application similar to the "Food to Go"-Application. For example, I have to enter new customers into the persistence mechanism. But before saving the customer, I want to check whether there is already a customer with that name (and address e.g.). Where would I put such checks?

- into the CustomerService.create(Customer c) method, i.e. into the domain-model
- into the CustomerFacade.create(Customer c) method, i.e. into the facade (I'm using a POJO-facade)
- into the CustomerRepository.create(Customer c) method ... obviously not such a good option, I think. Because it should only be responsible for getting/saving data to/from the pers.mechanism, not the business-logic.
- into some sort of Validator which gets involved on trying to save the customer ... but then this Validator had to have access to the Repository to check whether there is already a similar customer. I'm using the Spring-framework, so I could probably use this:
- another question: could the validation be put (partially) to the client-side? (I don't have a web-application...)
- how should I inform the client, that there's been a validation error? Throw a CustomerValidationException (but then there was no way to inform the client about what errors there were...) or stick with the return of a status-object like in "POJOs in action"?

Please help me, I'm lost with these desing-decisions smilie
Thanks in advance!
ceracm (113) [Avatar] Offline
Re: Design-questions: where to put validation?
A couple of comments:

1. I would be inclined to put it in the service. Its part of the core functionality of creating a customer so I would not put it in the facade.

2. You could expose the check as a separate method to allow it to be done in the client although that might not be to useful. You might as well make a single request to create a customer rather than first check to see whether you can.

3. You could throw a CustomerExistsAlreadyException. Or you could return a status-object. Which one is best is a matter of taste and of requirements.

I hope this helps.


PS. Sorry for the delay in replying. I was on vacation.
urgo (2) [Avatar] Offline
Re: Design-questions: where to put validation?
But shouldn't this validation be in domain object itself?

At least if one uses Spring, Hibernate and exposes domain objects not DTOs to presentation (JSP) as Javabeans.

Here is sample scenario that I came across recently:

1) user submits request to change Customer name
2) Spring binds request parameters to domain object and calls its setName. If there is no validation in domain object then we have now domain object in invalid state in our system.
3) service starts to validate Customer by calling CustomerRepository.getByName() but before this method is actually called Hibernate starts synchronizing session with database. While doing so Hibernate tries to save this invalid Customer. If there is db constraint "customer_name_unique" then we get an exception even before service can start actual validation.

I'm not big specialist in Hibernate so the situation above could possible be avoided by some configuration change but otherwise we can't add validation to anywhere else than inside domain object setName.
simbo1905 (30) [Avatar] Offline
Re: Design-questions: where to put validation?
@urgo Your scenario would not happen if you manage transaction management correctly. The following post discusses that hibernate does not commit until the hibernate session is closed. JTA has its own solution. The book uses a façade to encapsulate the atomic actions in a single transaction:

In the question where to put the validation I would recommend "at the narrowest possible scope". If the validation is scoped to one entity put it into the entity. If the validation is scoped to multiple entities put it into the service. If we consider the façade to be be a "re-usable entry point service between different clients" then you could put it into the façade.