Ticket Q427358
Visible to All Users

Using Xpo, WCF, OData

created 13 years ago

I have started a new WPF application and need advice related
to using XPO, WCF, OData, etc.

From an architectural point of view the application is a WPF
client connecting to WCF services using XPO as the data provider.

There are a few key elements I need to implement in the
application:
-
- The WCF services should expose data not only to
my own WPF client but should also be available to third-party clients. Thus, I
need to implement various access levels to the data available through the WCF
services (using roles/permissions, etc.) to restrict access to particular
database tables. I do not wish to expose all available data in the database.

-
- The data model should give me a way to expose non-persistent
data (e.g. calculated fields on the server side).
-
- The WPF client will use DevExpress grids and
other controls and performance is critical because the amount of data could be large.
Most likely I have to use InstantFeedbackDataSource for the grids (or similar)
to improve performance.

I have tried different scenarios to expose the data:
-
- XPO/OData via WCF data services

-
- XPO via WCF services (using the information
found here).
My first attempt was using XPO with OData (i.e. WCF data
services). This was working just fine for my needs. However, later on I
realized that XPO/OData does not provide me a way to expose non-persistent data
(XPO class properties marked with the NonPersistent attribute) and it is not
clear when/if this will be available in the future. Exposing non-persistent
data is crucial, so I abandoned this approach.

XPO via WCF services (e.g. using the DataStoreService class)
does not provide me a clear way to restrict access to particular database tables.
It seems that I would have to implement my own solution for restricting access
based on application requirements and individual user credentials.

What is the recommended approach to exposing XPO classes
using WCF services while allowing for non-persistent data and restricting
access to specific data on an individual user basis?

I'd really appreciate any assistance.

Best Regards,
Oleg Mironov

Answers

created 13 years ago (modified 13 years ago)

Hi Oleg,
Thank you for your question. In the current version, non-persistent members cannot be exposed because there is no way to inform the client that a property is read-only. I believe it should be possible to address your requirements via new OData3 features. Microsoft WCF Data Services 5.0 released on 8/15/2012 includes OData3, which allows you to publish annotations, where you can specify that a property is read-only. Additionally, OData3 supports the QueryInterceptor and ChangeInterceptor methods that receive the information gathered from the HttpContext request. You can use them to implement authorization. Also, OData3 supports Service Operations, Service Actions, Streams and Named streams, and settings for filtering and sorting.
Our developers are working on including the Odata3 support in the XPO Library. I hope it will be ready soon so we will publish this functionality with version 12.2.

    Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

    Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.