This is a more clear explanation.

 

Now, you say "The above recommendation was written before Code-First and it still holds for Model-First and DB-First"

 

I think that is necessary to divide the DEVFORCE documentation in two big groups: "Code first" and "Modelfirst or dbfirst". I think that would be more clear if each group have the same topics as now: Start, Model, Query, Display, Create Modify and Delete, Validate etc. I feel that exist specific tips and tricks to each approach. May be some information is shared.

 

thanks again.

 

 

In Code-First you have options. Mapping and validation are two seperate concerns and it is unfortunate that Microsoft decided to fold them in one with the data annotation attributes. DF keeps them seperate for good reasons, so we don't want DF Verifiers to describe the mapping.

 

As I said there are options with CF, so let's look at them. There is the purist approach. In the purist approach you'll leave your entities free of attributes alltogether. To describe the mapping you rely on EF conventions and the Fluent API, where conventions don't apply. This way you don't use the data annotation attributes at all. Now you can use DF Verifiers to describe all your validation rules. DF also allows you to define the validation rules outside of the entity class, leaving your entity classes free of validation attributes.

 

Most developers use a combination of EF conventions, data annotation attributes and Fluent API. It's less code to write in the end. In this case you are in the situation where you find yourself having a "large" amount of code that already uses .NET attributes. The word "large" is relative here, but you get my point. You start with the .NET attributes. At any point you can augment with DF Verifiers when it gets past basic validation or you can use the Cocktail custom validation approach or a combination of all three.

 

There is no clear line in the sand, or at least we haven't settled on one. In TempHire I follow the most common approach. I started with EF conventions and then added data annotations attributes, where EF conventions don't apply and then used the Fluent API for DB Initialization. This is the natural path most developers follow. If you follow this path then you'll primarly use .NET validation and resort to DF Verifiers or Cocktail custom validation when you reach the limits of .NET validation.

 

 

 

From documentation in http://drc.ideablade.com/xwiki/bin/view/Documentation/validation-generate-attributes

 

"We recommend that you use use DevForceVerification unless you have a compelling reason to do otherwise (e.g., you have a large amount of code that already uses the .NET attributes and facilities). DevForce verification provides a superset of the capabilities provided by .NET validation."

 

Regards

 

 

May be you can to influence on the DevForce team. :)

 

Do you recommend EF DataAnnotations over DevForce DataAnotations?

 

thanks