DevOps Zone is brought to you in partnership with:

I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. Martin is a DZone MVB and is not an employee of DZone and has posted 79 posts at DZone. You can read more from them at their website. View Full User Profile

Contextual Validation: Martin Fowler Retread

11.04.2011
| 6109 views |
  • submit to reddit
This is a Retread by Martin Fowler of an earlier version of this post which was first published in 2005.  Definitely worth a read.

In my writing endeavors, I've long intended to write a chunk of material on validation. It's an area that leads to a lot of confusion and it would be good to get some solid description of some of the techniques that work well. However life is full of things to write about, rather more than time allows.

Some recent readings made me think about saying a few preliminary things on the topic. One common thing I see people do is to develop validation routines for objects. These routines come in various ways, they may be in the object or external, they may return a boolean or throw an exception to indicate failure. But one thing that I think constantly trips people up is when they think object validity on a context independent way such as an isValid method implies.

I think it's much more useful to think of validation as something that's bound to a context - typically an action that you want to do. Is this order valid to be filled, is this customer valid to check in to the hotel. So rather than have methods like isValid have methods like isValidForCheckIn.

One of the consequences of this is that saving an object to a database is itself an action. Thinking about it that way raises some important questions. Often when people talk about a context-free validity, they mean it in terms of saving to a database. But the various validity checks that make this up should be interrogated with the question "should failing this test prevent saving?"

In About Face Alan Cooper advocated that we shouldn't let our ideas of valid states prevent a user from entering (and saving) incomplete information. I was reminded by this a few days ago when reading a draft of a book that Jimmy Nilsson is working on. He stated a principle that you should always be able to save an object, even if it has errors in it. While I'm not convinced that this should be an absolute rule, I do think people tend to prevent saving more than they ought. Thinking about the context for validation may help prevent that.

reposted on 03 Nov 2011

Published at DZone with permission of Martin Fowler, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Aaron Digulla replied on Tue, 2011/11/08 - 9:10am

You may want to refactor this sentence: "But one thing that I think constantly trips people up is when they think object validity on a context independent way such as an isValid method implies." :-)

Aaron Digulla replied on Tue, 2011/11/08 - 9:36am

The web has taught us something new: Non-save or save-less applications where the application simply remembers state without any "Save" or "Submit" buttons.

Eclipse did it a couple of years ago with a Java compiler that would compile anything into a valid Java class files - only some code would throw an Exception explaining that the compiler couldn't compile it. What seems like a ridiculous idea at first glance - what's the point of getting an executable that contains a compiler error?? - it does allow for some problem solving strategies which were impossible otherwise:

- Fix breaking changes one unit test at a time
- Find code that isn't executed by unit tests (for all those poor people who don't use code coverage tools)
- Get interrupted with a new, important task

Sure, all of those do have solutions but with the new compiler, there is another arrow in my quiver.

I've attempted something similar with my ePen project. It's an editor for authors and it doesn't have a save button anywhere. Data is saved as you type. This means I'll commit invalid objects to the database. Just like in Eclipse, objects need to be validated again after fetching them from the database and the error messages must be restored/merged.

It's an interesting approach which surprised me more than once. With a "Save-now" type of application, you have transactions. As a developer, you know when something is "ready" for the next step of the process. In a Save-less application, the code must understand this by itself.

Example: Character names are often unique, so I create links for them automatically. This seems innocent enough. The next step is back-links: A list of links on the character description to all the places where he is mentioned. A bit more complicated - mostly because of performance issues.

It starts to get interesting when the author changes the name of a character: What should I do while the name field has focus? Refresh all the links everywhere with every key press? How do I know when the author is finished? Is focus lost enough or should I refresh after 250ms of inactivity? How do I keep the link indexes up-to-date while the name is changed?

In this context, validation gets rules that you wouldn't expect. Things like: "Abort the current validation because a new change has just come in" or "delay the validation for 250ms after the last change". In a similar fashion, triggering a validation rule in one object can trigger more validations in other objects - which triggers all the usual "avoid the loop" problems.

Robert Craft replied on Thu, 2012/01/26 - 6:08am

Different tasks in business applications often require that the information to be edited meet special requirements. Sometimes end-user actions may not meet these requirements. Let's consider a simple instance, where an end-user fills out a form with personal information. It is usually necessary to fill out required fields, but the end-user may be unaware of this. Special notifications should be provided to ensure that all required data is entered. Another instance concerns internal business logic in an application. For example, a rule may require that the total sum of an order must not exceed a certain value.

Spring Security

Carla Brian replied on Sat, 2012/06/30 - 11:09am

I think this would be effective. I want to learn more on this. I will definitely study this one. - Mercy Ministries

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.