Congrats Colin on joining I21!

Hi Colin,

interesting write up.

However, I have to admit I'm not confident about the fact that the validator should directly check a duplicated user.

I'd make this kind of validation into the middle tier (your userService), eventually throwing an exception and *then* letting the Spring validator (*not* the MVC controller) dealing with it.

What do you think?

Cheers!

Sergio B.

[quote]the point I am making is that the validation can be in any tier, because the Spring validator is tier-agnostic.[/quote]
Colin,
Is there any code sample how to perform validation using Validation framework in application which does not have web layer? (no web.war, Spring MVC, Controllers, or any MVC to that matter)
Validation on purely service layer.
Can you share it?

[quote] Sergio, there is no way that the validator has access to the exception thrown by the middle tier.

Sorry Colin, I didn't explain well.
What I meant is: you can inject your middle tier service (userService) into the validator and let the validator call the userService for ensuring user uniqueness.
I have to say I don't like this solution too much, but if you want to move all validation logic into the validator, what would you do?
Like Arno says, maybe some code sample would help.

However, too bad, I think that all that kind of validation logic strictly related to application use cases (creation of entities, performing of business operations) *doesn't* fit well into the validator.
This is because you *cannot* separate the performing of business operations (in your example the creation of an User) from their validation (in your example the User uniqueness): this practice could lead to an incorrect domain state.
Neither you can use the validator into your domain, because this would actually separate the two aspects above and couple the domain with external validation logic (I'm a DDD guy), nor you can use the validator into your middle tier, because if you call the validator into your middle tier for enforcing business logic, and *then* the same validator is called by the web controller, you get two calls for the same validator.

Again, I think you should make some detailed example.

My two euro cents.

Cheers!

Sergio B.

[quote] Of course account.withdraw(10) should throw InsufficientFundsException, but do you not think the validator should also verify that account.withdraw(10) would succeed (account.getFunds()>10, or account.canWithdraw(10) == true)? I do. [/quote]

Colin, I don't think so: I don't see any value added in verifying this rule *also* in a Validator.

[quote] To create a new user, you need to specify a password and a confirm password.
A User should *never* expose a getPassword(), rather, a rich domain model that followed good OO should also follow encapsulation and therefore contain a user.isPasswordValid(proposedPassword).
If you are proposing that the User *does* contain a get/setPassword and get/setConfirmPassword then surely you are actually going down the anaemic domain model; the exact antithesis of DDD. [/quote]

I fully agree with you, and if you read my blog you can understand my way of thinking.
I think getters/setters should be avoided as much as possible, but I don't like those kind of DTOs like your RequestToCreateUser: I prefer a lot to use rich domain objects, eventually decorating/adapting them with additional getters/setters (like your get/setPassword and get/setConfirmPassword) using AOP introductions.
Shameless plug: I'm a Spring Modules developer and founder of the XT Framework module, containing, among other things, also an implementation of such a thing, based on Spring AOP.
However, this is off-topic and would deserve a whole post on its own.

[quote] We are both agreeing on the end goal (rich domain models), but yet we both seem to discredit each others approach [/quote]

I don't think we are discrediting anything: we have different approaches, which is a good thing.
If everyone had the same approaches and ideas, there would be no discussion, and so no further learning … don't you think?

So yeah, rock on!

Cheers!

Sergio B.

Hi Colin,

I just want to make sure I've got what you're saying. So thinking about the implementation, you would have a UserValidator that might be injected with a UserService (or whatever provides a username lookup) to do lookup of the username like so:

public void validate(Object obj, Errors errors) {
User validatingUser = (User) obj;

// username validation
ValidationUtils.rejectIfEmpty(errors, "username", "error.required");

if (userService.isUsernameExists(validatingUser.getUsername())) {
errors.rejectValue("username", "error.user.exists",
new Object[] { new DefaultMessageSourceResolvable("username") },
"Username already in use");
}
}

public void setUserService(UserService us) { ….. }

By the way, congrats on joining Interface 21.

Brendan

I've just linked to this post from my blog as part of Blog Surprise and BlogDay fun. Thanks for being an unwitting participant . Nice design here – I'm intrigued at how well you and your team have constructed this thing.

Hello Collin,

just thee questions on your discussion:

1. As you suggest to have one single validator class for one business object and want to have uniqueness being checked, how do you distinguish between objects that are being created and those who are being edited. If you check an user being edited for a unique username you of course will find "another" one in the database, which is absolutely correct because its the object to be edited.

2. Could you give some heuristics or starting points where to place validation logic calls in layers? What is actually obvious is validating objects in contolles at web layer. Validating at service methods that receive objects to be worked with might be a good guideline but that would actually scatter validation calling code through the first lines of those service methods. Maybe AOP could help there?

3. What still is not clear to my mind is the programming model of the validator if not used in controllers (where you actually don't have to directly call or access them). I actually also couldn't find any examples except the ones were validators are used in contollers that provide some kind of best practise of how to use them. Also the Javadoc is not really useful there, like it is while programming SimpleFormControllers e.g.

Thanks in advance,
Ollie

Just a question here: if you have a UserValidator to ensure that a username is unique, how do you know the context?

IE, if I want to validate a User upon insert, its not ok to have a duplicate, but if its an update, I cant follow the same validation logic?

BTW, we are using the validator not against forms, but in our application layer

How does your validator know if its an insert operation or an update operation?

If its an insert, I can see how you can detect the duplicate, but an update shouldnt have the same case.

Hi Colin,

with all the information in this blog (thx all), i have now implement the folowing design and i hope it is useful for anyone. The example checks if one name is already exists (insert & update) in the database.

public class LandValidator implements Validator{
private ValidationManager validationManager;
public ValidationManager getValidationManager() {
return validationManager; }
public void setValidationManager(ValidationManager validationManager) {
this.validationManager = validationManager; }

public boolean supports(Class clazz) {
return Land.class.isAssignableFrom(clazz); }

public void validate(Object obj, Errors errors) {
ValidationUtils.rejectIfEmptyOrWhitespace(errors, "name", "NAME_REQUIRED", "Name Required.");
if (errors.getErrorCount() == 0) {
boolean chkConstraint = validationManager.chkLandNameExists((Land)obj);
if (chkConstraint) {
errors.reject("NAME_ALREADY_EXISTS", "The Name already exists.");
}
}
}
}
The Validator call the service layer Validator Manager Interface. The implemantation is like:
public class ValidationManagerImpl implements ValidationManager{
private LandDAO landDAO;
public LandDAO getLandDAO() {
return landDAO; }
public void setLandDAO(LandDAO landDAO) {
this.landDAO = landDAO; }

public boolean chkLandNameExists(Land land) throws RuntimeException {
return landDAO.chkLandNameExists(land);
}
}
Last the Implementation of the DAO:
class LandDAOImpl extends HibernateDaoSupport implements LandDAO{

public boolean chkLandNameExists(Land land) throws RuntimeException {
List tmpList = getHibernateTemplate().find("from Land l where l.name=?", land.getName());
if (tmpList.isEmpty()) {
return false;
} else if (carrier.getId() == null) {
return true;
} else {
for (Iterator it = tmpList.iterator();it.hasNext();){
Land tmpLand = (Land)it.next();
if (!tmpLand.getId().equals(land.getId()))
return true;
}
}
return false;
}
}

I hope there is no typing error in my example.

Thx for all information
Michael

I did make a education on the topic of "Web Application Security" recently.

Of course, Input Validation was a big topic itself. I did suggest 2 approaches:
* either do the validation within the domain object itself
* use a validation framework (I did of course mention the Spring validation stuff)

Now both appeal to me. I did see some arguments for the validation within the domain object itself
* the domain object would be "secure by default"
* the validation would be baked-in

The main disadvantage seems to be the fact that you cannot change the validation rules (i.e. the validator implementation). You could do this by informing the domain object about the current context it is in (e.g. in web context, where the users' address simply has to make sense, and the business logic layer, where the address has to be checked against a directory of sorts)

What are your opinions on the issue of validation done inside vs. outside of a domain object?

btw: it's great to hear that I am not the only one concerned with this issue. And it's great to hear that interface21 (or whatever its called now) is taking it seriously. Go on with the verbosity level, it's appreciated…

Just ran into this thread. The original post is somewhat presumptuous, besides being rather arrogant:

>> but this is a very *very* small window (typically milliseconds),
How's milliseconds a very small window? Sounds as big as any. If transactional integrity is violated, it doesn't matter what the window is. If it can happen – it will happen.

>> and an OptimisticLockingException would probably thrown anyway
Optimistic locking is performed for existing objects. The original question, I believe, comes from inserting a new record, i.e. optimistic locking exception will not be thrown away.