Validation::Class as a Data Modeling Framework
An Unexpected Side-Effect.
Recently I been experimenting with using Validation::Class (v5.50+) to provide a self-validating data model in various projects. The DRY approach the library enforces ensures data integrity through consistency.
I personally prefer to check incoming data once and ensure it meets a specific criteria then move on throughout various layers in the application stack with a level-of-certainty that the input is as it should be, ... sort've a set-it-and-forget-it point-of-view.
Prior to recent changes, the general idea was to have application developers create a validation class in addition to an existing data/object model (which is twice the work), this was the reasoning behind having the framework ship with a half-baked Moose adapter.
The two main changes in Validation::Class are, automatic generation of attributes based on field names, and the method keyword which creates self-validating routines (sorta like method signatures). Simple as it may seem, these two changes allow developers to easily create data models and objects with validating attributes and methods with built-in validation and error handling while remaining fast and extensible due to its lean dependency chain.
It's Your Party, You Can die() If You Want To.
Validation::Class won't die on instantiation (or anywhere else for that matter) unless you tell it to. The ignore_failure flag when set to false will confess to method validate failures. The ignore_unknown flag when set to false will confess to an attempt to validate a parameter with no matching field definition.
Although the sentiment may not be shared by all, error handling is one of those things I'd just like to be there without worrying too much about how its setup. Validation and error handling are built-in mechanisms you are encouraged to leverage.
I Am So Made That I Cannot Believe.
The following is a reasonably realistic albeit lame example of Validation::Class usage scenarios: