locked
Custom Data Source (i.e. not Entity Framework) Guidance RRS feed

  • Question

  • Hello all,

    I'm looking for some guidance in exposing a custom data source (existing .NET API for CMS documents) using ADO.NET Data Services. I'll explain the data model in simplified terms; essentially the issue is that the entities in the system do not expose their properties as typed .NET properties, but as dynamic, named attributes--and I'm trying to find a model/approach that will allow clean querying based on the values of those attributes. The data model is:

    The main entity of concern is a Document, which has an arbitrary number of named (a string name) Attributes. Each of these Attributes can have one of more Values, which (for simplicity's sake) we'll say are each of some EDM Primitive Type. (There are a few other possible types, like XML, but they should all be expressable as one of the primitive types.)

    (Document [has many]-> Attributes [has many]-> Values [has a]-> $value of some primitive type)

    The most important query scenarios would be retrieving a Document, or set of Documents (along with their associated Attribute Values, expanded) by querying against some combination of Attribute Values.

    The problems I'm running into are that (1) Data Services won't let any URIs/filters get through (to my custom IQueryProvider) that don't correspond directly to static .NET types (which is as designed, I'd imagine), and (2) I'm not certain how to go about retrieving a grandparent entity based on grandchild attribute values (i.e. get a Document based on a the $values of the Values some given Attributes of that Document).

    Hopefully I explained that clearly enough; I can elaborate if need be. Any advice would be much appreciated.

    Thanks.
    Friday, September 26, 2008 9:40 PM

Answers

  • Data Services won't let any URIs/filters get through (to my custom IQueryProvider) that don't correspond directly to static .NET types (which is as designed, I'd imagine)

     

    Yes, this is by design for V1. In V2, we are working on something called dynamic metadata, for which you don't get static .Net types. In V1, you will have to have a backing static .Net class for each type and was William said, EF tools can do this for you.

     

    Thanks

    Pratik

    Monday, September 29, 2008 4:50 PM
    Moderator

All replies

  • If this was a database, it would seem to be fairly straight forward with 3 tables. Documents-->Attributes-->Values with relations between them.  Then just add a EF model from the DB and your pretty much done as it builds the objects for you.  If not using some DB, then I would create .Net objects with properties to expose your data and host those objects as the datasource.  You gen dynamic data inside them if needed.

    http://channel9.msdn.com/posts/mtaulty/ADONET-Data-Services-VS08-Sp1-B1-Surfacing-Data/

    Sunday, September 28, 2008 1:05 AM
  • Data Services won't let any URIs/filters get through (to my custom IQueryProvider) that don't correspond directly to static .NET types (which is as designed, I'd imagine)

     

    Yes, this is by design for V1. In V2, we are working on something called dynamic metadata, for which you don't get static .Net types. In V1, you will have to have a backing static .Net class for each type and was William said, EF tools can do this for you.

     

    Thanks

    Pratik

    Monday, September 29, 2008 4:50 PM
    Moderator