I’ve started to experiment with the RIA Services Framework and I’ve noticed that it uses the “buddy class” pattern that I first saw in ASP.NET dynamic data.

The basic idea is that you’ve got some class that is generated by a tool (pseudo-code);

public partial class MyClass

{

  public int MyProperty { get; set; }

}

and you want to provide some additional metadata around those properties but you can’t just stick an attribute onto the property definitions themselves because you’ll lose them when the tool regenerates them ( assuming the tool doesn’t have its own repository for those attributes which it can use to put them back at generation time ).

So, what do you do? The ASP.NET dynamic data model adds another by doing something like this;

[MetadataClass(typeof(MyMetadataClass))]

public partial class MyClass

{

  public int MyProperty { get; set; }

}

public class MyMetadataClass

{

  [Range(1,100)]

  public int MyProperty{ get; set; }
}

that is – it introduces a companion or “buddy” class which is used purely to store the metadata attributes that you wanted to put onto the properties for the first class but couldn’t because those properties were tool generated.

Now…I must admit that when I first saw this I didn’t really like it. I suspect I’ve got a couple of reasons why I feel uneasy about it;

1. It seems that we’re introducing quite a lot of artefacts – i.e. an additional class, an additional property and an additional attribute purely to specify one thing – the range of the property should be 1 to 100. Do I really need an additional class, property and 2 attributes to specify that?
2. I’m not sure that I like the idea of adding classes to my code base that no piece of code will ever instantiate and use. It feels odd to me to introduce classes purely to provide metadata.
3. Clearly there’s a gap between the original class and the metadata class which can introduce errors (as simple as naming errors) which you may not get to see until runtime.

For me, I think I’d have rather seen;

1. Additional inputs to the code generation process. That is – some XML file that is taken at build time and used as part of the code generation process in order to further attribute the generated code with attributes like Range above.
1. One aspect of that is that for ASP.NET dynamic data you’re often using code generated by LINQ to SQL ( not really a pluggable process ) or LINQ to Entities ( is a pluggable process ) so it might not have been so easy for the dynamic data folks to plug in to that process.
2. Metadata stored externally to the code. That is – some XML file that is taken at run time and combined with the code in order to further attribute the generated code with attributes like Range above. I’m thinking something like (pseudo-XML);

<metadata>

  <typeExtension type=”MyClass”>

    <range minValue=”1” maxValue=”100”/>

  </typeExtension>

</metadata>

I appreciate there’s a bit of a risk in the separation implied in (2) in that you can get a mismatch between the XML configuration and the code-base but I think it’s perhaps worth it for the flexibility that it gives you in being able to (e.g.) change these definitions without cracking open the code.

That’s my 2p on these “buddy classes” – I’m not overly keen on them and they seem to be springing up in more places. Has anyone else taken a view on it?