I have DTOs that are mapped to ViewModels. To avoid having to manage validation attributes (and other attributes), I wanted to write the validation attributes for all the properties on a single class and reuse it on my ViewModels. However, when I try to use the Metadata on a ViewModel that does not have all the properties of the DTO (all of them really...), it gives me an System.InvalidOperationException
exception.
Exception:
Le type de métadonnées associé pour le type 'MyProject.EntityViewModel' contient les propriétés ou champs inconnus suivants : AnotherProperty. Vérifiez que les noms de ces membres correspondent aux noms des propriétés du type principal.
Google translated:
The type associated metadata for type 'MyProject.EntityViewModel' contains the following unknown properties or fields: AnotherProperty. Verify that the names of these members match the names of the properties of the main type.
Simplified example:
public class Entity {
public string A { get; set; }
public string B { get; set; }
public string C { get; set; }
}
public class EntityDTO {
public string A { get; set; }
public string B { get; set; }
public string C { get; set; }
}
//This class is used to add validation attributes for input-related view models
public class EntityInputValidation {
[Required]
public string A { get; set; }
[Required]
public string B { get; set; }
//Notice that we dont have a validation for C
}
//This class is a ViewModel used to create a new Entity
[MetadataType(typeof(EntityInputValidation))]
public class EntityCreateViewModel {
//Required because we use the InputValidation metadata
public string A { get; set; }
//Notice that we do not have the B property here, even if we are using the Input Validation which has a required attribute for this property. This is where the exception comes from.
//C is only required in this View/ViewModel
[Required]
public string C { get; set; }
}
Because EntityViewModel does not have AnotherProperty
, it will throw an exception. Is there a way to prevent this?
I would certainly reconsider having those annotations directly on your entity. As you can already see, this is going to cause you problems whenever you need to use that entity in a view which doesn't need to adhere to those validation rules. That will likely get worse in the long run if more views are added which use your entity.
Pretty much whatever solution you come up with to stop that throwing the exception is going to be a hack.
Updated per comments
I did not want to search into 20 view models whenever we have to change a validation rule... We currently have 2 websites and soon to be 3 that are part of the solution using the same DAL and business logic. Thats a lot of view models to keep updated.
That is certainly a valid concern, and this is also a valid question to be asking. The problem is more that there is no well-defined solution, at least that I've found.
Taking a look at the inheritance idea, it seems reasonable at first. However, this is only going to work if your properties fit into neat groups, which from your updated question seems may not be the case.
Let's take a simple example:
public class LoginValidation
{
[Required]
public string Username { get; set; }
[Required]
public string Password { get; set; }
}
You could then derive a view model from that:
public class ViewModelA : LoginValidation
{
public string SomeOtherProperty { get; set; }
}
However, this comes with a problem. What if you want to inherit another set of validation properties? You can't, as we're restricted to inheriting from one class. We also cannot inherit data annotations from interfaces:
The product team does not want to implement this feature, for two main reasons:
- Consistency with DataAnnotations.Validator
Consistency with validation behavior in ASP.Net MVC
tricky scenario: a class implements two interfaces that have the same property, but with conflicting attributes on them. Which attribute would take precedence?
(Source: http://social.msdn.microsoft.com/Forums/en-US/1748587a-f13c-4dd7-9fec-c8d57014632c/code-first-dataannotations-in-interfaces?forum=adonetefx)
So what if you need LoginValidation
and some dates validation for a specific view? You'd have to create an inheritance chain from both in an intermediary class, just to be able to inherit from that for your view model:
public class LoginAndDateValidation : LoginValidation
{
[Required]
public DateTime StartDate { get; set; }
[Required]
public DateTime EndDate { get; set; }
}
public class ViewModelA : LoginAndDateValidation
{
public string SomeOtherProperty { get; set; }
}
Do you see where this is going? This would turn into a complete mess. So, as I said earlier, this will only work if your properties fit into, and are used in, well-defined groups, but it doesn't seem that is the case in your scenario.
To finish up, let me just link to an answer Mystere Man posted a few years back that I've always liked: https://stackoverflow.com/a/8075115/729541