I haven’t done much work with ASP.NET Dynamic
Data but in a recent project I started
working with it and instantly ran into a dilemma. First, let me explain
the project setup.
I have a database project that outlines the schema of the database, the
stored procedures, all of that. I have a database client project that
has some services and a LINQ to SQL data context that I can distribute
to clients who want to go that way. I then have a Dynamic Data project
for managing the data and a separate web application that will consume
the data, both of which need the LINQ to SQL data context.
Switch on your suspension of disbelief for a second with respect to the
design. I could do a way better design going more SOA, or using a
repository pattern, or whatever, but it’s a spike project and part of
the goal is for me to learn something about Dynamic Data, LINQ to SQL,
and so on.
Now, Dynamic Data uses the LINQ to SQL data context - from the client
assembly - to do its work and generate its screens. Here’s the problem:
In order to control the rendering of the Dynamic Data screens, I have
to have a metadata “buddy class” to describe it. In order to have a
“metadata buddy” class, I have to add an attribute to the generated LINQ
to SQL model class that points to the metadata type.
See the problem? The Dynamic Data app is the only thing that cares about
the metadata “buddy class,” so that’s where the class will live… but
if I have to mark up the original LINQ to SQL class in a separate
assembly to get that to happen, I’m hosed.
Here’s what a standard scenario looks like:
[MetadataType(typeof(ResourceMetadata))]
public partial class Resource
{
// Resource is a class in the LINQ to SQL
// generated data context. A partial class
// declaration allows us to put the metadata
// attribute on it.
}
public class ResourceMetadata
{
// The metadata class can define hints for
// the Dynamic Data UI as to how to render
// view/edit controls for the similarly named
// property on the LINQ to SQL model class.
// This declaration says 'render this as a
// ResourceValue type.'
[UIHint("ResourceValue")]
public object Value;
}
As you can see, we have to mark up the LINQ to SQL class with that
MetadataTypeAttribute.
I don’t want to do that… but how to keep the metadata separate from
the model?
The key is in the Global.asax.cs of your Dynamic Data project. The
line where you register the data context with the application:
MetaModel model = new MetaModel();
model.RegisterContext(typeof(DataLibrary.ResourceDataContext), new ContextConfiguration()
{
ScaffoldAllTables = true
});
See that “new ContextConfiguration” bit? One of the parameters you can
pass is
“MetadataProviderFactory.”
That parameter is a delegate that creates an instance of something
deriving from
“System.ComponentModel.TypeDescriptionProvider.”
The default behavior is similar to this:
MetaModel model = new MetaModel();
model.RegisterContext(typeof(DataLibrary.ResourceDataContext), new ContextConfiguration()
{
ScaffoldAllTables = true,
MetadataProviderFactory =
(type) => {
return new AssociatedMetadataTypeTypeDescriptionProvider();
}
});
The default MetadataProviderFactory is
System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptionProvider.
That provider uses an internal type (of course it’s internal) that
gets the metadata type for a model class through reflection.
In order to get your metadata class from somewhere other than
reflection, you need to make your own TypeDescriptionProvider.
Fortunately, that’s not actually too hard.
First, let’s decide what we want to do: We want to have a static
mapping, similar to the MVC route table, that lets us manually map a
LINQ to SQL type to any metadata type we want. If there’s no manual
mapping, we want to fall back to default behavior - get it through
reflection.
Now we know what we want the outcome to be, let’s get cracking. Throw
together a place where you can hold the metadata mappings:
using System;
using System.Collections.Generic;
namespace DynamicDataProject
{
public static class DisconnectedMetadata
{
public static Dictionary<Type, Type> Map { get; private set; }
static DisconnectedMetadata()
{
Map = new Dictionary<Type, Type>();
}
}
}
I suppose if you wanted to get really fancy with it you could have
add/remove/clear methods that have a bunch of thread locking around them
and such, but this is a simple way to go and most likely you’re only
going to be registering mappings at app startup so all of that would
just be overkill.
Next we have to create a
System.ComponentModel.CustomTypeDescriptor.
What a CustomTypeDescriptor does is get all of the information about the
various metadata - attributes and properties - on your buddy class. The
thing is, Microsoft already did all of that for us, they just
inconveniently marked the type they use -
System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptor
-
as internal. With a little fancy, maybe slightly unsupported,
reflection work we can pretty easily make use of the code that’s already
there. Instead of doing a giant full implementation of a new
CustomTypeDescriptor, we can write a wrapper around the existing one.
using System;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Reflection;
namespace DynamicDataProject
{
public class DisconnectedMetadataTypeDescriptor : CustomTypeDescriptor
{
private static Type AssociatedMetadataTypeTypeDescriptor =
typeof(AssociatedMetadataTypeTypeDescriptionProvider)
.Assembly
.GetType(“System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptor”, true);
public Type Type { get; private set; }
public Type AssociatedMetadataType { get; private set; }
private object _associatedMetadataTypeTypeDescriptor;
public DisconnectedMetadataTypeDescriptor(ICustomTypeDescriptor parent, Type type)
: this(parent, type, GetAssociatedMetadataType(type))
{
}
public DisconnectedMetadataTypeDescriptor(ICustomTypeDescriptor parent, Type type, Type associatedMetadataType)
: base(parent)
{
this._associatedMetadataTypeTypeDescriptor = Activator.CreateInstance(AssociatedMetadataTypeTypeDescriptor, parent, type, associatedMetadataType);
this.Type = type;
this.AssociatedMetadataType = associatedMetadataType;
}
public override AttributeCollection GetAttributes()
{
return AssociatedMetadataTypeTypeDescriptor.InvokeMember(
"GetAttributes",
BindingFlags.Instance | BindingFlags.Public | BindingFlags.InvokeMethod,
null,
this._associatedMetadataTypeTypeDescriptor,
new object[] { }) as AttributeCollection;
}
public override PropertyDescriptorCollection GetProperties()
{
return AssociatedMetadataTypeTypeDescriptor.InvokeMember(
"GetProperties",
BindingFlags.Instance | BindingFlags.Public | BindingFlags.InvokeMethod,
null,
this._associatedMetadataTypeTypeDescriptor,
new object[] { }) as PropertyDescriptorCollection;
}
public static Type GetAssociatedMetadataType(Type type)
{
if (type == null)
{
throw new ArgumentNullException("type");
}
// Try the map first...
if (DisconnectedMetadata.Map.ContainsKey(type))
{
return DisconnectedMetadata.Map[type];
}
// ...and fall back to the standard mechanism.
MetadataTypeAttribute[] customAttributes = (MetadataTypeAttribute[])type.GetCustomAttributes(typeof(MetadataTypeAttribute), true);
if (customAttributes != null && customAttributes.Length > 0)
{
return customAttributes[0].MetadataClassType;
}
return null;
}
} }
We’re doing a few interesting things here to be aware of:
- On static initialization, we get a handle on the original
AssociatedMetadataTypeTypeDescriptor - the internal type that does
all the attribute reflection action. If we don’t get a reference to
that type for some reason, we’ll throw an exception so we
immediately know.
- We have a GetAssociatedMetadataType method that you can pass any
type to - ostensibly a LINQ to SQL model type - and you should come
back with the correct metadata buddy class type. First we check the
type mapping class that we created before and if it’s not there, we
fall back to the default behavior - getting the
MetadataTypeAttribute off the LINQ to SQL class.
- The two-parameter constructor, which is used by Dynamic Data, is
where we call our GetAssociatedMetadataType method. That’s our
point of interception.
- The three-parameter constructor, which lets a developer manually
specify the associated metadata type, creates an instance of the
original AssociatedMetadataTypeTypeDescriptor and passes the
information into it first. We do that because that type has a bunch
of validation it runs through to make sure everything is OK with the
metadata type. Rather than re-implementing all of that validation,
we’ll use what’s there. We’ll hang onto that created object so we
can use it later.
- The GetAttributes and GetProperties overrides call the
corresponding overrides in that
AssociatedMetadataTypeTypeDescriptor object we created. We do that
because there’s a lot of crazy stuff that goes into recursing down
the metadata class tree to generate all of the metadata information
and we don’t want to replicate all of that. Again, use what’s there.
That’s the big work, seriously. A wrapper around
AssociatedMetadataTypeTypeDescriptor pretty much does it. Last thing
we have to do is create a System.ComponentModel.TypeDescriptionProvider
that will generate our descriptors. That’s easy:
using System;
using System.ComponentModel;
namespace DynamicDataProject
{
public class DisconnectedMetadataTypeDescriptionProvider : TypeDescriptionProvider
{
public DisconnectedMetadataTypeDescriptor Descriptor { get; private set; }
public DisconnectedMetadataTypeDescriptionProvider(Type type)
: base(TypeDescriptor.GetProvider(type))
{
this.Descriptor =
new DisconnectedMetadataTypeDescriptor(
base.GetTypeDescriptor(type, null),
type);
}
public override ICustomTypeDescriptor GetTypeDescriptor(Type objectType, object instance)
{
return this.Descriptor;
}
}
}
As you can see, this basically just provides an override for the
“GetTypeDescriptor” method and hands back our custom descriptor.
That’s the entirety of the infrastructure:
- The map.
- A CustomTypeDescriptor that looks in the map and then falls back
to reflection.
- A TypeDescriptionProvider that uses our CustomTypeDescriptor.
To use this mechanism, in your Dynamic Data project you need to register
the mappings and register the TypeDescriptionProvider. Remember the
“model.RegisterContext” call in the Global.asax.cs file in the
RegisterRoutes method? Add your mappings there and when you call
RegisterContext, add a MetadataProviderFactory:
public static void RegisterRoutes(RouteCollection routes)
{
// Register types with the map
DisconnectedMetadata.Map.Add(typeof(DataLibrary.Resource), typeof(DynamicDataProject.ResourceMetadata));
// When you register the LINQ to SQL data context,
// also register a MetadataProviderFactory pointing
// to the custom provider.
MetaModel model = new MetaModel();
model.RegisterContext(typeof(DataLibrary.ResourceDataContext), new ContextConfiguration()
{
ScaffoldAllTables = true,
MetadataProviderFactory =
(type) =>
{
return new DisconnectedMetadataTypeDescriptionProvider(type);
}
});
// ...and the rest of the method as usual.
}
That’s it. Now you don’t have to mark up your LINQ to SQL objects with
partial classes- you can put your metadata “buddy classes” anywhere
you want.
There are some optimizations you could make for performance purposes
that I didn’t do here for clarity. For example, rather than call
“InvokeMember” on every call to GetAttributes and GetProperties in the
CustomTypeDescriptor, you could cache references during static
construction to the MemberInfo corresponding to the two methods and
invoke the cached references. This should get the idea across, though.
And, of course, the usual disclaimers apply: YMMV, I’m not
responsible if this code burns your house down or crashes your app or
whatever, etc., etc. Works on My Machine!
