There’s lots of stuff written around dynamic data elsewhere so I won’t duplicate it here. I did a little bit of experimentation with it today rather than just watch Mike walk me through it.
My first surprise in springing up dynamic data was this dialog;
It looks like I have to choose between a “Dynamic Data” web site and a “Dynamic Data Entities Web Site”.
That seems a bit odd to me. If you look at what the ADO.NET Data Services folks did in terms of being “data neutral” then you get to;
- Expose any object graph read-only you like as long as it has a few necessary attributes on it
- Expose LINQ to SQL data read-only ( again possibly needing a few attributes )
- Expose either ( 1 or 2 ) read-write by adding IUpdatable
- Expose LINQ to Entities data read/write by default.
So, there’s a pretty nice story around being data source neutral. It makes for a simple demo where you can just take a few CLR types and expose them over REST without having to get into any other data access technology.
It looks like Dynamic Data doesn’t have that approach just yet – in fact, you can see that it’s heading towards something along those lines when you look at the futures page.
I went down the LINQ to SQL route for a while and the next thing I wondered was whether I could use stored procedures to do the CRUD behind this data access. I suspect not although it might be possible to configure the CUD stored procedures for a particular entity type in LINQ to SQL and have stored procedures invoked for INSERT/UPDATE/DELETE and I gave that a whirl and it does seem to work fine.
One thing about this – it’d have been nice if LINQ to [SQL/Entities] allowed you to configure a “GET” stored procedure on a per-entity type and then I could have had Dynamic Data using my stored procedure to get its entities. Naturally, this would be a bit “anti-LINQ” given that SPs are not composable but, nonetheless, it’s a valid choice for a shop that uses SPs for everything.
The next thing that puzzled me about dynamic data is its choice of putting the metadata into the code. If I build a Dynamic Data site out of my Northwind database then I can get some customisation by doing something like;
public class OrderMetadata
{
[DisplayName("My Region")]
public string RegionDescription { get; set; }
}
[MetadataType(typeof(OrderMetadata))]
public partial class Region
{
}
That is – I add to the partial class Region which was generated for me by LINQ to SQL’s code gen. I add to that class purely to add another attribute called MetadataType and that attribute points to another class. In my case, that’s OrderMetadata.
Now, this is where things get a little weird for me. As far as I can tell, that other class is purely being used as a container for metadata. That is, it’s just a place to store a bunch of attribute values that cannot easily be added to the original Region class itself because there’s not really a notion of using a partial class to add attributes to an existing property.
I find this all a bit odd.
For me, I think I’d prefer that the Dynamic Data tooling just generated an XML file that it loaded at runtime and used that to store all metadata that it needed so that you could keep this stuff out of the code. It’d be even nicer if that format could be made to line-up with the XML format that LINQ to SQL already ( optionally and not by default ) uses to keep its object-relational mapping metadata outside of your code. It’d be even nicer still if Dynamic Data gave you a little editor for editing that XML format inside of Visual Studio.
Regardless, you can’t always get what you want and, right now, you get this slightly odd (imho) use of classes purely as a means of storing metadata.
Other than that, my experimentations with Dynamic Data weren’t anything out of the ordinary 🙂 Check out the videos here;
if you want an intro.
Mike Taulty 