Fowler on Validation
I just read Martin Fowler's ContextualValidation entry in which the following statements triggered me:
Martin indicates he prefers the use of contextual validation methods such as
I am a strong believer in separating information management, business process management and UI dialog management responsibilities. In my book information management is about enforcing context-free constraints on business data, to ensure that this data has and maintains certain semantics (e.g. weight is a positive number, end data cannot be less than start date, total volume of packages in a warehouse cannot be more than volume of warehouse).
Business process management is about coordinating the automated and manual activities required to gather a piece of meaningful information. Though a business process may take a long time to get all the data it needs, it either finishes with a commit of the gathered information into an information management system (or service/component/object, whichever term you prefer) or it gets cancelled. A business process management system may well store information itself, but it is of a different nature and/or with different semantics. While a business process is running, the collected information only has meaning to the participants in the business process.
For example, while a customer is on the phone to an energy supplier to set up a direct debit, only the customer and the customer service person on the other end of the phone line can (to a certain degree) assess the validity of the information collected so far. It is only when both the customer and the customer service representative both agree that all the required information is there and of sufficient quality that this information is committed to the customer database of the energy supplier and becomes relevant and meaningful to the rest of the organisation. So business information systems manage data that is regarded as 'fact' by the whole organisation. Business process management systems manage (the collection and storing of) work-in-progress data with limited meaning to anyone else than the people directly involved.
An object-oriented implementation of these ideas would involve the creation of business workflow classes/component/services that coordinate business process execution and business entity classes/components/services that are responsible for information management (terminology borrowed from Application Architecture for .NET: Designing Applications and Services). A
- "one thing that constantly trips people up is when they think object validity on a context independent way such as an
isValidmethod implies." - "Alan Cooper advocated that we shouldn't let our ideas of valid states prevent a user from entering (and saving) incomplete information."
Martin indicates he prefers the use of contextual validation methods such as
isValidForCheckIn rather than a single isValid method. I would agree it is wise to separate out various types of validation, but I am far from sure whether that should be in the form of multiple isValidForXXX methods on say a Customer class.I am a strong believer in separating information management, business process management and UI dialog management responsibilities. In my book information management is about enforcing context-free constraints on business data, to ensure that this data has and maintains certain semantics (e.g. weight is a positive number, end data cannot be less than start date, total volume of packages in a warehouse cannot be more than volume of warehouse).
Business process management is about coordinating the automated and manual activities required to gather a piece of meaningful information. Though a business process may take a long time to get all the data it needs, it either finishes with a commit of the gathered information into an information management system (or service/component/object, whichever term you prefer) or it gets cancelled. A business process management system may well store information itself, but it is of a different nature and/or with different semantics. While a business process is running, the collected information only has meaning to the participants in the business process.
For example, while a customer is on the phone to an energy supplier to set up a direct debit, only the customer and the customer service person on the other end of the phone line can (to a certain degree) assess the validity of the information collected so far. It is only when both the customer and the customer service representative both agree that all the required information is there and of sufficient quality that this information is committed to the customer database of the energy supplier and becomes relevant and meaningful to the rest of the organisation. So business information systems manage data that is regarded as 'fact' by the whole organisation. Business process management systems manage (the collection and storing of) work-in-progress data with limited meaning to anyone else than the people directly involved.
An object-oriented implementation of these ideas would involve the creation of business workflow classes/component/services that coordinate business process execution and business entity classes/components/services that are responsible for information management (terminology borrowed from Application Architecture for .NET: Designing Applications and Services). A
CustomerCheckIn class would provide a natural home for the IsValidForCheckIn method, whereas the CustomerEntity class would solely have context-free information management reponsibilities, and one isValid method could well do the job. That is context-free as in not business process state dependent. A Customer object may still have a limited number of states (such as active/non-active/archived) that reflect the long-term life cycle of customer data.
