title: Is sharing MetadataType classes a good idea?
body: <p>We're building a site using Entity Framework and ASP.NET MVC, and I'm currently working through our models ensuring that all of the string properties have the appropriate validation attributes, and it's getting to be rather tedious.</p>
  
  <p>Most of the time, our views are populated from view models - POCO classes that are defined to provide backing data for specific views. In the rarer cases where we are using EF-generated classes to populate views, we're using the MetadataTypeAttribute to specify a metadata class for each.</p>
  
  <p>It's common for us to have a number of view models wrapping the same EF classes - exposing those parts of them that are used in a specific view. So it's common for us to have the same properties appearing many times across different models. Which means we need to specify identical StringLengthAttributes in multiple places. And if we accidentally specified different string lengths, for the same property in different models, it'd be an error that we'd not be able to easily catch.</p>
  
  <p>What I'm wondering is whether we could use the MetadataTypeAttribute - that instead of specifying separate validation attributes on every property, everywhere, we created a single metadata class with proper attributes for every property we use across the system, and applied it to each of our models with the MetadataTypeAttribute.</p>
  
  <p>Would there be any problems in specifying properties in a metadata class that weren't in the class it was applied to? Everything compiles fine, but that's no guarantee of issues.</p>
  
  <p>What happens when attributes are applied to a property in the main class and to the matching property in the metadata class? Are they all applied? If the same property is applied to both, which one prevails?</p>
  
  <p>It'd be easy enough to test how things work in my current version of .NET, but I've learned not to trust that, very much. I'm much more interested in what is defined behavior that I can count on not to change in future versions, than in what works at the moment.</p>
  
  <p>And beyond whether this will work, is it a good idea?</p>