I have blogged a little bit about ADO.Net Data Services (aka Astoria) and Microsoft MDM of late and once briefly mentioned the two in the same breath. As I have gotten to know a bit more about these two technologies I have been thinking more about how they might one day work together and I'm going to outline those thoughts in this blog. Before I begin let me give a short elevator pitch describing the two for those that haven't heard of them before:
- ADO.Net Data Services is a beta technology from Microsoft that is intended to make data available over HTTP
- Microsoft MDM is a beta technology whose intention is to ease the modelling and storage of the master data (e.g. customer, employees, products) that defines a business
As soon as you brush the surface of the two technologies you realise straightaway that there is some common nomenclature between the two. ADO.Net Data Services is built on top of the Entity Framework (link) whilst the fundamental building block of Microsoft MDM is an entity. In the rest of this blog entry I'll explore more about the similarities between the two and also some problems that are faced when trying to use them both together.
Let's explore Microsoft MDM first. The screenshot below comes from the recently released CTP of Microsoft MDM. I have highlighted 3 things:
- 3 entities that I have defined: {Person, Home Town, Country}
- 5 members of the [Person] entity: {Harry, Isabel, John, Julie, Paul}
- The entity [Home Town] which has been defined as an attribute of [Person]. [Home Town] has 4 members: {Leeds, London, Toulouse, Paris}
I haven't shown it here but there are also 2 members of the [Country] entity: {United Kingdom, France}. What I also haven't shown is that in the same way as I have defined [Home Town] to be an attribute of [Person], I have also defined [Country] to be an attribute of [Home Town]. So, given that I have defined these relationships between my 3 entities, Microsoft MDM can infer the following hierarchical relationships between the three entities:
Again the screenshot immediately above is taken from Microsoft MDM. As you can see, the relationships that I define between my entity members give rise to a hierarchy where a collection of [Person] members roll up to a [Home Town] member and a collection of [Home Town] members roll up to a [Country] member. In other words:
- [Country] <-- [Home Town] <-- [Person]
I should probably stress that again because its important. I didn't have to manually build this hierarchy, Microsoft MDM was able to infer it from the relationships that I have defined between my entities. That is a very powerful feature to have available.
Microsoft MDM has a lot of other features that I'm not going to talk about here but I thought it was important to convey the basic functionality which is:
- modelling of entities and
- the relationships between those entities
OK, that's it for MDM for the moment, let's turn our attentions to ADO.Net Data Services and the Entity Framework.
The Entity Framework is a suite of technologies than enable you to build an Entity Data Model (EDM) over the top of a data source. What's an Entity Data Model I hear you ask? Well the short and sweet answer is it takes your physical data model and turns it into something more akin to a conceptual model that is more use to developers. [Greg Low has published a pretty good explanation of an Entity Data Model using a passenger/flight/flight-manifest metaphor so it might be worth your while going to read that.]
So, the Entity Framework and Microsoft MDM both talk about entities. Therefore, would it not make sense to use the Entity Framework to build an EDM over the top of the database that underpins Microsoft MDM? I believe that it would and that's what I've built. Here's a visual representation of the EDM that I have built over the top of the MDM database containing my [Person], [Home Town], [Country] entities that I talked about above:
Looks fairly intuitive right? We have three entities and we can see the one-to-many relationships between them. And the similarities between this and the entities described above are hopefully immediately obvious.
| Caveat: I must point out that the Entity Framework uses unique key and foreign key declarations in the database in order to derive the entity relationships. Microsoft MDM doesn't (currently) declare these keys in its database so I cheated here by declaring them manually. |
ADO.Net Data Services is a technology that consumes the data provided by an EDM and makes it available over HTTP via a RESTful web service (don't worry too much about what RESTful means for now). I'll have a demo of that working in a later blog entry (so feel free to subscribe :) ).
So, ostensibly it looks as though the inherent features of Microsoft MDM and the Entity Framework will play well together but unfortunately that's not the case. Let me explain by pointing two very important facets of these technologies:
- In Microsoft MDM the entities are defined and modified AFTER the system has been deployed. i.e. At run-time
- In Entity Framework the entities are defined BEFORE the Entity Data Model has been deployed i.e. At design-time
Microsoft MDM is a lot more dynamic in nature than Entity Framework hence any time I make a change to my entities in Microsoft MDM (which could happen often) I would have to redesign and redeploy my Entity Data Model and that simply isn't acceptable unless your Microsoft MDM model is static.
I brought up this matter on the ADO.NET Entity Framework and LINQ to Entities (Pre-release) forum. In my post there I said:
I'd like to make a feature request. I would like the ability to define new entities at execution-time. i.e. After the entity data model has been deployed.
Jeff Derstadt and Brian Dawson from the Entity Framework team took the time to reply and here is what they said:
- This set of scenarios is very interesting to the Entity Framework team and attention is being given to these more dynamic technologies. Dynamic languages are growing in popularity and it will be important for the EF to address these new requirements. - Jeff
- I agree that having an EDM representation over MDM makes a nice programming platform. I'll bring this up to the bulldog team. - Brian
Interesting stuff I hope you'll agree. I'm not very au fait with dynamic languages but I know there is a groundswell of interest in them so the Entity Framework, and .Net in general, is going to have to address that. If you want a full read through of the discussion then head here.
-Jamie