An Open Letter to the Microsoft Data Teams About Enums
First off, I just want to say that I think the work you guys have done over the last 6 years has been awesome. Seriously. It has never been easier to get information into an out of a database, and throw it over a service. And the work with EF 5.0 on .NET 4.5 has brought with it some outstanding work in performance, usability, and especially support for Enums.
But this improvement has come at a price. Because OData does not officially support the concept of a first-class Enum type, if you are using any of the methods of leveraging OData (WCF Data Services or the new WebApi OData support, specifically) your code will break without any kind of warning. Why? Because "Enum" is itself a new enumeration entry in the EdmTypeKind, and there is not a build of WCF Data Services explicitly for .NET 4.5 that filters this type out while initializing entities. In WCF Data Services, the metadata startup code only checks for one value in the EdmTypeKind enumeration, and assumes all others will work on the "Else" codepath... which is not true for Enums.
So if you update a project running EF5 + WCF Data Services to .NET 4.5, you will be greeted with a low-level failure on your services that cannot be overridden without hundreds of lines of reflection code (believe me, I've tried).
It is amazing to me that you guys at Microsoft can even get away with this kind of breakage without repercussions. The downloads for EF5 or WCF Data Services do not explicitly state that you cannot add Enums to your model if you want to still be able to run WCF Data Services. I guess you guys just assume that it won't be an issue, because Enums are new and people won't try to build services that support them.
If you assumed that, you were wrong.
But it doesn't have to be this way. I've asked those among you several times why there is no support, and the answer I keep getting back is somewhere along the lins of "we'll have first-class support someday". But there is a big gap between "first-class support" and "fail at a level so low our built-in method of excluding or mapping types hasn't even kicked in yet".
Enums are backed by CLR primitive types: Int32, Int64, Byte, just to name a few. So why are you so worried about being able to represent the enumeration type fully in the $metadata document? Services like Twilio (see the Status field) use either the string or integer representation of the Enum, and force the developer to know what the integer values are. Either way, it is the developer's responsibility to enter them correctly. If you don't, they fail.
So why can't you do it this way? Why can't you do what your previous design forced thousands of EF developers to do: have an internal backing property that represented the integer version of the Enum, and then convert back and forth to the Enum at runtime? The answer is, of course you can. You guys just had other priorities. Which I understand. But not shipping bits that break in existing applications should have been a priority too. Or at the very least, having clear documentation that warns them of the problem before they spend time implementing it, identifying the problem, and trying to work around it.
This is easily fixable, especially in the new WebApi formatters. Just make it work like every other property, serialize the number for the underlying type, and let us developers work out the details of how to get the value into and out of the system the way we want to.
And please do it fast. I'd really like to ship this API I've been working on for the last few months.
Respectfully,
Robert McLaws
Entity Framework Enthusiast & .NET Developer