This project is read-only.

Attributed Validation and reusable entities

May 22, 2009 at 11:59 AM

Hi Olmo,

just studying your framework and find your validation attributes.

Think about a scenario, where you want to have a entity called 'Person' which holds the usual data, like name, social secutity number, day of birth ...

Now you want to use this person in some project and decorate the properties with validation attributes. Later on, you start developing another application, which also needs a class 'Person', so good oo tells us, reuse the 'Person' class.

Nice idea, you start out, but now you found, that this time the validation has to be changed a little. But you cant't do this without breaking the first applications code. Bad situation. Now you can inherit from your generic 'Person' class and override all properties, which needed different validation attributes, but if this is the majority, you just start out to write a new 'Person' class, its the same work.

What do you think about this scenario, and whats your idea to solve it?

One solution may be to use a seperated rules engine. Now you can reuse every class of every other project ((or build a generic entity library)) and apply the rules, you just need in your concrete application under development. This time, signum framework just drops off the list of possible candidates, didn't it?

I first developed a attributed validation solution for one of my projects and was enthusiastic about the cleanness of code of the entities. I use OpenAccess by Teleric (former Vanatec) to persist the objects, and feel like in heaven. But as I try to resuse some of my work, I get mad of this issue with attributes.

 

With best regards

Gerhard

PS: OpenAccess is also a entity first approach, which is the only truth, but also have a reverse engineering tool, so you can dock old databese designes with reasonably amount of work. If you want to take a look, www.telerik.com

 

May 23, 2009 at 10:18 AM
Edited May 23, 2009 at 10:24 AM

Hi Gerard

In fact, I've been looking to FluentValidation in order to enable an scenario like this, but I'm not convinced yet. My reasons:

  • You don't know what rules may change in the second application, so in order to be prepared you have to extract ALL the validations from the entities to a separate class, doubling the number of classes.
  • Not sure how external validation will work with Imperative validations (custom logic and multi field).
  • Our validation strategy also involves Invalidation: the ability to notify changes in PropertyB validation when PropertyA changes, this makes WPF UI much more responsive to the end user. A very cumbersome technique will be necessary to enable this if validation is in a separate class.
  • I find external validation more complex and hard to maintain, you will also need a Dictionary relating each entity class with their current validator class, both in Client and Server application. 

We currently have a way to modify FieldAttributes at runtime through SchemaBuilderSettings and we could do the same for validation attributes (on client and server App in this case).

However, is currently impossible to add a new field/property to a class for the second application only (a very likely requirement) and in this case the whole 'reutilization castle' will fall down and you will have to fall back to copy-paste your entities and a mayor refactoring will take place. That's why I remain skeptical about sharing classes and assemblies with business entities in different applications and I'm not sure if it's worth to invest more in this area at this time (other cools stuff coming soon :P).

Finally, I've found FluentValidation quite cool, a really good choice for server-only validation (or a not very responsive client validation) and when your entities have been auto generated, but this is not our scenario.

Thanks for your feedback, is allways good to know what people thinks about our work.

Kind Regards, 

Olmo.

 

May 23, 2009 at 7:09 PM
Hi Olmo,
ok, you see also an issue reusing entities in different projects. I came out with the same result. But I detect some situation, where I have different 'persons' in my project, with more than 80% identical properties, but very different ruleset. Thats the point I start thinking about my attributed validation framework, which clearly fails.
I also try to be as responsive on errors as possible. There two kinds of rules, adhoc rules, executed at each key stroke and final rules which only checked just bevore the business object gets persisted, like 'name required'. This system overcomes the funny behavior of some samples, where you start typing something into a required field, than delete the whole input to make a new start, but the system tells you, that the input is reqired ....
There are some frameworks which concentrating the rule in a seperated classes, but you are right its hard to deliver all the rules to the places they were needed.
Ok, hope I found some reasonable compromise for my project soon.
With best regards
Gerhard


Von: olmo [mailto:notifications@codeplex.com]
Gesendet: Samstag, 23. Mai 2009 11:19
An: gerhard.kreuzer@liftoff.at
Betreff: Re: Attributed Validation and reusable entities [signum:57169]

From: olmo

Hi Gerard

In fact, I've been looking to FluentValidation in order to enable an scenario like what you are explaining, but I'm not convinced yet. My reasons:

* You don't know what rules may change in the second application, so in order to be prepared you have to extract ALL the validations from the entities to a separate class.
* Not sure how external validation will work with Imperative validations (custom logic and multi field).
* Our validation strategy also involves Invalidation the ability to notify changes in PropertyB validation when PropertyA changes, this makes WPF UI much more responsive to the end user. A very cumbersome technique will be necessary to enable this if validation is in a separate class.
* I find external validation more complex and hard to maintain, you will also need a Dictionary relating each entity class with their current validator class, both in Client and Server application.

We currently have a way to modify FieldAttributes at runtime through SchemaBuilderSettings and we could do the same for validation attributes (on client and server App in this case) but still, is currently impossible to add a new field/property to a class for the second application only (a very likely requirement) and in this case the whole 'reutilization castle' will fall down and you will have to fall back to copy-paste your entities and a mayor refactoring will take place. That's why I remain skeptical about sharing classes and assemblies with business entities in different applications and I'm not sure if it's worth to invest more in this area at this time (other cools stuff coming soon :P).

Finally, I've found FluentValidation quite cool, a really good choice for server-only validation (or a not very responsive client validation) and when your entities have been auto generated, but this is not our scenario.

Thanks for your feedback,

Olmo.