locked
WCF data services without using ORM RRS feed

  • General discussion

  • Hi All,

    Is it possible for WCF data services to work with simple poco's with out using ORM? I would like to handle the data filling part as the data gets filled from various data sources and ORM cannot support all. We would like to expose this collected data over OData. So the simple question is IS ORM neceseaary for WCF data services? Can some one point to links that will explain how this kind of WCF DS needs to be written.

    Thanks and regards

     


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Monday, April 11, 2011 2:49 PM

All replies

  • Hi,

    Welcome to WCF Data Services forums!

    Are you looking for how to create WCF Data Services on Reflection based provider? 
    http://msdn.microsoft.com/en-us/library/dd728281.aspx
    http://msdn.microsoft.com/en-us/library/dd723653.aspx

    Reflection provider enables us to use WCF Data Services on the data which is strictly defined in an entity-based model.

    We also have some code samples in All-In-One Code Framework, the samples are named CSADONETDataService and VBADONETDataService.  They are for WCF Data Services v1 (named ADO.NET Data Services), but I think they can be helpful to you.   Feel free to let me know if you have any questions.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Tuesday, April 12, 2011 2:28 AM
    Moderator
  • Hi Michael,

    I will look into the links. But I'm trying to understand what you are saying. Do you meant to say that we will be able to use WCF data services with using EF or an other ORM. Does this kind of example exist in All-in-code framework ?

    Thanks and regards

     

     


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Wednesday, April 13, 2011 1:43 AM
  • Hi,

    The All-In-One Code Framework samples demostrates using WCF Data Services on three providers: EF, LINQ to SQL and Reflection based provider.  EF and LINQ to SQL should belong to ORM, but the Reflection based provider does not. 

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Wednesday, April 13, 2011 1:47 AM
    Moderator
  • Hi,

    Thanks for your speedy reply. But please tell me will this affect performance as the name has reflection on it. I ask this because I just wanted to ensure that it is not using Reflection internally in such a way that the service throughput is affected.

    Also let me know if All-in-code-framework has reflection providers sample. If not please point me to a link that has.

    Again thanks for your assistance.

    Thanks and regards


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Wednesday, April 13, 2011 1:55 AM
  • Hi,

    Based on the MSDN documentation the Reflection provider here, http://msdn.microsoft.com/en-us/library/dd723653.aspx, Reflection is used to infer the inside data strucuture:

    "In addition to exposing data from a data model through the Entity Framework, WCF Data Services can expose data that is not strictly defined in an entity-based model. The reflection provider exposes data in classes that return types that implement the IQueryable interface. WCF Data Services uses reflection to infer a data model for these classes and can translate address-based queries against resources into language integrated query (LINQ)-based queries against the exposed IQueryable types. "

    For performance, I don't think it will affect much.  The samples I mentioned in my first post contains Reflection providers sample.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Wednesday, April 13, 2011 5:53 AM
    Moderator
  • Hi,

    I went through the link. I see that the entiner container class ( the class that expose IQueryable<dataItem>) expose these entity types as static property. Is this a mandatory one ? Will these lead to concurrency issues ? How is the concurrency issues handled.

    Thanks and regards

     

    Wednesday, April 13, 2011 6:08 AM
  • The example code in the topic How to: Create a Data Service Using the Reflection Provider (WCF Data Services) is actually rather simplistic in that it doesn't implement the IUpdatable interface and therefore it doesn't support updates and, by extension, concurrency. If this sample did include an IUpdatable implementation (which I opened a bug to suggest that we add)  the static collection declarations mean that clients would be making changes to a shared instance of in-memory objects. This is kind of in-memory persistence is still a bit trivial, and your existing ORM certainly does something much more useful. The static collections are not a requirement, and your ORM probably doesn't manage your objects in this way anyway.

    By default, OData and WCF Data Services employ an optimistic concurrency model, which means that last change in wins and clients can stomp on each other's updates. However, you can specify that the data service actively manage data concurrency by using HTTP eTags headers, which the data service does for you automatically when you mark your entity classes in the reflection provider with the ETagAttribute. When the data service sees this attribute, it checks for concurrency before attempting to make updates.

    Cheers,

    Glenn Gailey


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, April 13, 2011 10:24 PM
  • Hi Glenn,

    Thanks for your inputs. If you could please see my initial post, I have mentioned by scenario because of which I cannot use any ORM like EF. I also understand that I will have to manage the persistence in my POCO objects only.

    I also understand for your reply that the static IQuerable<<dataItem>> classes are for retrieval purpose only. So do you suggest that I use Static property for retrieval and then instance bound methods to perform the updates ? Or do you suggest that we do not have to use any static declarations at all.

    Thanks and regards


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Thursday, April 14, 2011 3:26 AM
  • I guess how you code your resource container (i.e. entity container), which is the class that exposes IQueryable<T> and implements IUpdatable, depends on how your reflection data provider implementation works. The data services runtime creates a new container instance for each request to the data service. By using a static constructor and static object collections, this data can be persisted in the container between calls to the service and shared between instances. In this example, we would want the IUpdatable implementation to update the shared entity data--perhaps I'll add this to the sample just for fun. But as I said, this is a fairly simplistic example meant to demonstrate the provider behavior, and most providers will end up persisting the data out somewhere and not just depend on in-memory structures.

    Glenn.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 14, 2011 7:21 AM
  • HI Glenn,

     

    Thanks for the inputs. So in my case could you please offer me some guidance as to how I should write my containers for IQueryable<DataItem> and for persistenace. I mean that what methods could be static and whether the persistence methods should be non-static or static.

     

    Thanks and regards

     


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Friday, April 15, 2011 1:37 AM
  • Again, it pretty much depends on the requirements of your individual implementation. I would use a static implementation for the collections used to store entities in memory provider, otherwise each call to the data service results in updates being made to different copies of in-memory data, but a given query would always just return the default entity data provided at instantiation.  

    You mentioned in your initial post having "various data sources." The point of the reflection provider is to provide the data services runtime with a way to be able to access data from these sources. This is done by creating a class (the container) that provides a set of methods where each returns an IQueryable<T> for each entity type that you want exposed by the data service. Then your IUpdatable<T> implementation must figure out how to get changes made against each entity type persisted back into each of your various data sources. There is also some assumption that entities in your model have some relationships with one another.

    When your data comes from various data sources (rather than a unified set of data--such as an ORM), you may require the flexibility of using our custom data service providers. These are more complicated to implement, but enable you to more easily handle various data sources, in particular data sources that are dynamic and may not be fully-known at design-time. This blog series can get you started with custom providers.

    Again, if you could provide a bit more info on what kinds of data sources you are looking to expose as OData feeds, I might be able to provide a more detailed response.

    You might also follow this step-by-step video useful: Build a WCF Data Services Using Any Data Source.

    Cheers.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, April 15, 2011 9:29 PM
  • Hi Glenn,

    The various data source are IMS and Sybase ASE 15. In case of IMS the data access to WCF data service is to be done using IBM Soap gateway. In case of Sybase ASE 15 the data access could be done either with ADO.NET drivers for Sybase ASE or using ODBC connectivity. The interesting fact is that both of these does not have an ORM access.

    Thanks and regards

     


    Venkatesh. S|MCTS(WCF, ADO.NET 3.5)|eMail: heman_1978@hotmail.com
    Saturday, April 16, 2011 12:53 AM
  • I see that a 3rd party solution from DataDirect offers a provider for Sybase ASE 15 that supports ADO.NET and the Entity Framework. However, I don't think it's possible to combine an Entity Framework provider with other data source providers to create a cohesive data service. Writing an IQueryable<T> implementation from scratch can also be quite a bit of work, but if you have an ADO.NET provider for Sybase that supports LINQ (.NET Framework 3.5 or later), you may be able to generate an IQueryable<T> from a DataView or some other data object in the a DataSet.

    As for the SOAP service, if it returns some kind of typed collection, the client proxy would probably materialize a response as some kind of collection, like a List<T> or IEnumerable<T>, and both of these have an AsQueryable<T>() method that returns a default implementation for IQueryable<T>, which you could then expose in your container class. This would give you at least basic query functionality in the data service.   

    To be honest, I've never tried either of these approaches. Also, you would still need to tackle the IUpdatable implementation to persist data back to the respective data source (unless the service is read-only).


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, April 16, 2011 8:28 AM