EF DataAnnotations vs Devforce DataAnotations

 

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.