So… what’s wrong with object.Validate()???

Today I was asked why choose a validation framework over good ol’ object.Validate(..) and given permission to publish the response.

     object.Validate is just fine except that the behavior doesn’t serialize
across the wire (it "will" if you re-instantiate the object on the
other side if you are using a shared assembly, but won’t if you are
using object generated from the proxy in things like JSON, AJAX, or
other client types what build their types from a WSDL or other schema. Often you will want the ability to do some
validation on a client prior to firing it across the wire. Or… should
the previous sentence read "firing it across to a long-running
process"? More on this…

    One thing I have been thinking about, when it comes to object
validation, was spawned by reading up on using enterprise service bus’. NServiceBus creator, Udi Dahan makes the distinction between "stateless services" like the classic calculator service and "statefull services", termed "sagas", which (and I hope I am close on this) can involve multiple domain objects but, more importantly, require state to complete their work. These ‘sagas’ are typically longer running, durable, transactionally processed messages that encapsulate business logic.

    My paraphrased definition for a statefull service likely does not do justice to the depth that is intended, but tie that binds the discussion of service purposing and validation is that there is often a struggle with how to do object validation in a re-usable (both sides of the wire) fashion. Validating that a type is not null or that it’s value is a member of a natural number set is not something that requires state. Making a call to a value object validation service may be able to provide that point of re-use. It can be called from a client prior to calling one of those long-running sagas and your statefull service when doing its initial cleansing of the data it’s receiving. Though that still incurs the cost of an additional network call (two if you consider that your statefull service will be calling the service as well), it frees those saga services from being bogged down with duplicated validation logic. This also enables you to use clients that can’t share your assembly (JSON, JAVA, etc.) to utilize the stateless validation service.

    So,  combining object validation frameworks with stateless services/services (SOA or otherwise)… there’s my thoughts for today. *signing off*

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s