Validation Attributes or Conventional Names
In my previous post I explained about how FubuMVC.Validation works (which btw is not part of the FubuMVC core) how it is using Convention over Configuration to determine what should be validated by which validation rule(s). By doing so it clearly separates the different concerns from each other, the view models don’t know about any validation and the validation framework doesn’t know about what specifically gets validates.
A common way of accomplishing validation is by placing specific attributes on the properties that need to be validated and the validation framework will use these to determine what rules it should be validated upon. I personally don’t like this approach, for one you have to configure each view model with the different attributes. The other reason is that I don’t like attributes (extra dependencies, possible hidden logic, looks plain ugly).
So FubuMVC.Validation does not use attributes to determine what to do when, it uses Conventions to determine what needs to be validated. These conventions can be based upon anything that you can determine from PropertyInfo class, an obvious choice is to use the property name as a filter.
The basis how conventions work is that you will apply the same logic to similar situations, so for example, a property containing an e-mail address would contain the word "Email" whether it is a personal or business e-mail address. When you adhere to these conventions, then you can create a validation convention that will validate all properties that contain the word "Email" with the IsEmail validation rule.
This is all great because it makes sense to name the properties in your domain something like PersonalEmail and BusinessEmail. The same applies to CompanyUrl, but what about OptionalCompanyUrl? Optional indicates a business rule, is this good or bad? Would it be better if this was done by be absence of a Required attribute? I believe that using this naming scheme will show proper intend of the domain model, and it places the business rules where they belong in the domain model. But then again I am not a DDD master.
Hi Steve,
I think the issue with magic string mostly is because of it not being compiler save and refactor friendly. Also Convention over Configuration is mostly a way of thinking so if you do something in a particular way in place A you should also do that in place B. This also makes sense from a developer point of view, if you have certain conventions you don't have to ask all the time what something does or is. Basically in being consistent you open up the possibilities for Conventions. Now in your case you can of course override / add / delete rules for properties that are not included in your conventions.
Also I think that using Conventions over Configuration is doing DRY with your configuration code.
Thanks for your comment.
-Mark
Mark Nijhof, Monday, March 23, 2009 at 12:54 AM
Yeah, I think that I agree w all your points. The issues that I have experienced with convention-over-configuration tend to be in cases where you ACCIDENTALLY violate the convention and recieve no error feedback, making debugging challenging.
As a simple example: name your FORM in ASPNET MVC 'customerForm' but set the controller action method param to be 'CustomerForm' and the arg passed to the controller will be NULL everytime since (by accident) the case doesn't match that used in the form. This is a source of A LOT of wasted time b/c the compiler has no way to know that I *meant* to use the same case for both the form and the controller action method argument.
In a very real sense, I think that we are trading one set of compiler-unsafe things ('magic strings') for another (conventions) and it reminds me of the old-addage about the DEMAND that you do unit testing with a dynamic language whereas its (at least possible if not recommended) to 'skip' unit tests in a static-typed language b/c the compiler is giving you a 'first line of defense'. Moving to more and more 'convention-over-configuration' just means that you skip unit-testing this stuff at your own (increasing) peril b/c so much of it is completely undetectable by the compiler.
All the same, its REALLY hard to write the unit test that says 'make sure that all the args to my controllers are found somewhere in my views form declarations' since they are strings in the view and method argument names (not even types!) in the controllers, for example.
Just some thoughts that fall into the 'no free lunch' category of consideration IMO. :D
-Steve B.
Steve Bohlen, Monday, March 23, 2009 at 1:12 AM
Recent blog posts
- Follow me @ Elegant Code
- CQRS à la Greg Young
- CQRS à la Greg Young example code
- My Kindle DX
- My book: Are You Better Than Yesterday?
- Running with Scissors
- Applying Domain-Driven Design and Patterns
- Hey Developer, YAGNI I tell you
- Hey Developer, the product you create is your code
- NDC videos are published
I often wonder why we consider 'magic strings' to be 'evil' and yet we consider 'magic property names' (like this) to be OK...? I'd certainly hate it for my object.EMail property to receive validataion while my object.e-mail property didn't (although *perhaps* my unit test would uncover this for me).
I know that I am off on the 'convention-over-configuration-is-a-pit-waiting-for-you-to-fall-into-it' island (nearly) all by myself, but this is (frankly) a dichotomy I cannot reconcile in my own mind *unless* I simply arrive at the conclusion that the (secret real) reason we hate 'magic strings' is just b/c the refactoring tools cannot easily support our use of them.
Thoughts?
Steve Bohlen, Monday, March 23, 2009 at 12:29 AM