Fort Knox Business Objects ( yes / no )

I’ve spent the last week at the Microsoft 2008 MVP Summit.  It was a fantastic learning and sharing experience.  Microsoft took excellent care of us the entire week.  Spending time with other MVP’s and meeting my friends from all over the globe was priceless.

I also spent a good deal of time out of the classroom with members from four different teams.  It was during these times that we had some very healthy,  animated discussions on topics that we are both passionate about.  In the end, we shook hands and parted with deep respect looking forward to our next discussion.

I don’t know about the readers of my blog, but I like passionate discussions.  I like to listen to other developers explain their approaches to problem solving and their solutions.  After the flamethrowers are put back in the armory, I then like time to think about why the other side was presenting their point of view.  Many times the “why” never comes out in the dialog.  That developers life experience normally does not get presented as part of a discussion on the .NET Framework.  So I like to marinade on the facts and work backwards to try to get inside the other persons world to understand why they want to adopt this solution.  This is known as inductive study.  By asking questions of the facts presented, you can many times determine context and then come to an understanding or appreciation of the process that lead to their solution.

The Scenario

I spent several hours talking about the concept of business objects throwing exceptions in the property setters if the value did not pass the validation rules for that property.  If you have read my latest article, WPF Business Application Series Part Three you know that I strongly favor using the IDataErrorInfo interface for business object validation broken rule notification as opposed to throwing exceptions from property setters.

I thought long and hard about the discussions and came to this conclusion, you either favor the Fort Knox or Shopping Cart approach to business object validation.  One is a controlling paradigm the other a trusting relationship.  One takes a very granular approach the other a holistic approach to business object validation.

In discussions, business object validation is normally centered around UI binding scenarios.  This is only one scenario and I would strongly argue that more validation takes place in the business layer processing of objects than direct UI binding.  So proponents of throwing exceptions as a form of broken validation rule notification, must take a step back and look at this notificaiton business from a much higher perspective than just a UI binding scenario.

I realize that there are two schools of thought here.  One states, an object should never be in a invalid state.  The other, allows for temporary broken rules, but verifies object state prior to any actual use of the invalid object.  This notion of absolute control or pure objects is an illusion that does not play well with real world business objects and today’s computer users.  Of course application scope and requirements must dictate how and when business rules are enforced.  As an architect I don’t want the platform to force me to write objects in a certain way just to utilize it, especially when there is no payback and only complicates development and code maintenance.  Framework developers are not responsible for my data, me and my developers are.

WPF is one example of permitting developers to choose a broken validation rule notification technique that suits their application.  It allows developers to use exceptions or IDataErrorInfo for broken validation rule notification to the class binding to it.

Fort Knox	Shopping Cart
Throws exceptions when a validation rule is violated in a property setter.  Guards each property setter with a machine gun, sounding general quarters any time a value does not pass all the rules.  The Fort Knox approach to shopping, would have the store manager walking with you.  Each time you add an item to the cart, the manager would be running your credit card and possibly forcing you to submit to a polygraph.  Your every movement would be recorded on video and watched real time by a security guard, waiting like a cat ready to pounce on its prey at the first sign of weakness. This approach makes validation rules that are dependent on two or more properties, very difficult to implement since the order that the property must be set can now become a factor when trying to avoid an exception being thrown.	Follows a passive validation model that maintains a listing of each broken rule in the object and provides a means to query an individual property or the entire object for its validation status.    The Shopping Cart approach to object validation allows the user to shop the store, place items in the cart and then check out.  In the above example the shopper can get feedback on items and their total as they shop, but are not prevented from adding the item to the cart. This approach only cares about the checkout process and not the act of placing an item in the cart as opposed to the Fort Knox approach that won’t let you place a second item in the cart until the first item is paid for.

Fort Knox Business Layer Problem

The Fort Knox approach can kill business layer code like LINQ queries that attempt to populate that object and the data is invalid for one reason or another.  I’ll use two examples to illustrate this problem.

If you have validation rules that are dependent on one or more property values, developers will now have to write code to set property values in a certain order to avoid an exception being thrown.  This is a crazy requirement and is contrary all .NET class design documentation.  Can you imaging having to wrap EVERY piece of code that sets a property with a try catch block.  Again, what about LINQ queries that are tying to populate objects and unnecessary exceptions are being thrown by property setters.  This makes writing maintainable code MUCH harder and with ZERO payback.  When code is changed over time, a field added, we have to factor in usless exception handling and be cognasent of the order in which property setters are called or change.

I was speaking to one of the team PM’s on Friday.  When I asked him about a certain issue his response was, “stuff happens.”  I agree with him, stuff does happen.  The Fort Knox approach does not allow for (actually tries to prevent) temporary invalid object state.  This all comes full circle to the Fort Knox developers that some how get this false sense of security from exceptions being thrown, as opposed to developers checking an object’s Error property or other properties that expose object state and collections of broken validation rules.  Any developer can read and learn this programming pattern from Rockford Lhotka’s CSLA, Microsoft’s Validation Application Block or Karl Shifflett’s Lightweight Business Object Declarative Programming.

Using the Fort Knox approach does not guarentee a valid object either.  The developer could go through the pains of catching exceptions, but the object is still invalid if it does not pass all the validation rules.

In reality both approaches do allow for tracking broken rules since the developer is free to write any code in each setter and then throw the required exception.  My biggest problem is having to code around what should be a reporting problem.  However, this still means that all business layer processing code would have to be on the look out for a broken validation rule exception each time a setter was accessed as opposed to business layer code checking the object validation state as a whole, prior to persisting or moving an object to another tier.

Close

I welcome your feedback on this topic.  Please comment on your approach to business object broken validation rule notification.  Good discussions lead to better programming techniques and educate all who participate.

Have a great day!

Just a grain of sand on the worlds beaches.