C# – Using enums in WCF Data Services

cenumsodatawcfwcf-data-services

I'm trying to manually build a WCF Data Service using a POCO data model and I cannot figure out how to properly expose enum values. Assuming a simple model like:

public class Order
{
   public int ID {get; set;}
   public string Description {get; set;}
   public OrderStatus Status {get; set;}
}

public enum OrderStatus
{
   New,
   InProcess,
   Complete
}

How do you expose the valuable information in the OrderStatus property via the OData WCF Data Service?

If you do nothing, the Data Service generates a runtime error (enum is invalid property). The only answer I've seen that at least resolves the error is to mark the enum property as Ignored, such as:

[System.Data.Services.IgnoreProperties("Status")]
public class Order ...

This works, but it forces you to "omit" valuable information from the service layer.
Are there other options for working with enum values in WCF Data Services?

EDIT: Please notice this is WCF Data Services (aka Astoria). This is not raw WCF Services, in which case the answers are more clear.

Best Answer

Enums are currently not supported in WCF Data Services (the OData protocol doesn't support them either). The typical workaround is to use string and constant values, or integer and constant values.

Related Solutions

Javascript – How to guarantee that the enums definition doesn’t change in JavaScript

Since 1.8.5 it's possible to seal and freeze the object, so define the above as:

const DaysEnum = Object.freeze({"monday":1, "tuesday":2, "wednesday":3, ...})

or

const DaysEnum = {"monday":1, "tuesday":2, "wednesday":3, ...}
Object.freeze(DaysEnum)

and voila! JS enums.

However, this doesn't prevent you from assigning an undesired value to a variable, which is often the main goal of enums:

let day = DaysEnum.tuesday
day = 298832342 // goes through without any errors

One way to ensure a stronger degree of type safety (with enums or otherwise) is to use a tool like TypeScript or Flow.

Quotes aren't needed but I kept them for consistency.

Wcf – Exposing data from WCF services as oData

WCF Data Services is the Microsoft implementation of the general OData protocol. As such, only WCF Data Services are / support / implement OData - a "normal" WCF service does not (and can not).

You might need to elaborate exactly why you feel the need or urge to use OData but not use WCF Data Services. What's the issue / problem you have with that setup? WHY do you want to use only a "normal" WCF service??

Update: ok, so you want to have services that expose data in different fashions and with different methods. What you could do is create a regular WCF service that's exposing both SOAP endpoints as well as a webHttpBinding REST endpoint. This will work - but then it's a "regular" WCF service, with methods that take parameters and return some data structure. This is not WCF Data Service (OData).

OData is more of a "here's my data collection, you can browse around in it" kind of approach - it's more about exposing an entire data model to the outside world using REST. This doesn't mix and match with SOAP - which is a lot more procedure-oriented, e.g. LoadCustomer, SaveInvoice and so forth.

So while it's absolutely possible to have procedure-oriented WCF services exposing both SOAP and REST endpoints at the same time, I don't really see how you can mix and match the "expose-this-resource" kind of approach for WCF Data Services / OData with a SOAP binding - this just doesn't work, I believe.

So if you must expose your data model of WCF Data Services (OData), you will need to author a second, pretty different looking regular WCF services for the SOAP clients, that might be based on the same data in the end (access the same database, for instance), but it's "face" will look quite different.

Related Topic

R – Make individual checkboxes on WPF datagrid not visible