3

The Entity Framework will not support enum's until EF 5.0 (scheduled to ship soon).

Entity Framework 4.2 enum support

http://blogs.msdn.com/b/efdesign/archive/2011/06/29/enumeration-support-in-entity-framework.aspx

http://visualstudiomagazine.com/blogs/data-driver/2012/01/entity-framework-4-3-gets-final-tune-up.aspx

WCF Data Services (and the oData standard) to not support enums

We understand that enums are common, unfortunately they never met tha bar so far. They are rather high on our list of things to do next though

(See: https://stackoverflow.com/a/3571378/141172)

I have begun a new project and am replacing enum's with something like:

public static class MyEnum
{
    public const int MyValue = 0;
    public const int AnotherValue = 1;
}

I'm sacrificing the guarantee that enum's provide that only defined values will be assigned in order to utilize important (and at this point fairly mature) infrastructure services.

Is there a better way to handle lagging enum support? Once EF and WCF Data Services add enum support, is there likely to be another important framework on the horizon that will introduce enum support as slowly as these two have?

Community
  • 1
  • 1
Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • Just a minor point for the education of readers. Enums do not validate that the value is one of the "named" values. I could easily pass ((Color)43) to anything that wanted a Color if Color is defined as public enum Color { Red, Blue, Green } – Ross Bradbury Feb 27 '13 at 17:25

2 Answers2

0

Well better than your example would be using an enum to hold the constant values and casting to int everytime. That way you can at least use the enum whereever it is possible rather than loosing everything.

enums never provide inescapable type-safety. But by extending the usage of enums as far as you can into the applications code and business logic, you get more and more safety against subtle usage errors.

usr
  • 168,620
  • 35
  • 240
  • 369
  • I used the cast-to-int pattern in a previous project. That pattern made my model messy by having an enum property for use in the code, and a matching just-for-persistence property that had to be public (for EF to use it) and could be confusing for the model consumer. – Eric J. Feb 07 '12 at 22:49
  • I'd use an int property only. – usr Feb 07 '12 at 23:00
  • I see... still, that's a confusing code contract e.g. for the UI developers, and there's nothing at all preventing them from directly assigning an int to the property. – Eric J. Feb 08 '12 at 00:00
  • Actually there's nothing preventing people assigning wrong values to the enum property either. Since the language/runtime doesn't prevent your from explicitely casting an int to any enum. So you don't get a runtime guarantee that the value will always fit into the enum. It just makes it look nice in IDEs. – Vitek Karas MSFT Feb 08 '12 at 13:03
  • @Vitek: And with Reflection, you can do almost anything... but it's unlikely imho that a UI developer will intentionally cast an int to a property that's defined as an enum. My concern is with presenting clear contracts, not with presenting contracts that are immune to abuse. – Eric J. Feb 08 '12 at 17:16
  • 1
    enums never provide inescapable type-safety. But by extending the usage of enums as far as you can into the applications code and business logic, you get more and more safety against subtle usage errors. – usr Feb 08 '12 at 18:23
  • I do agree with the "usability" part. And actually if OData would support it would very likely also validate this on the server input, so that would help a lot. Unfortunately it doesn't support it yet :-( – Vitek Karas MSFT Feb 08 '12 at 19:55
0

Could you use a struct with a private constructor that defines a public static member for each value:

public struct FakeEnum
    {
        public static readonly FakeEnum MyValue = new FakeEnum(0);
        public static readonly FakeEnum AnotherValue = new FakeEnum(1);

        private readonly int _value;

        private FakeEnum(int value)
        {
            _value = value;
        }

        public int Value { get { return _value; } }

        // TODO: Equals and GetHasCode and Operators Oh My!
    }

Note: I haven't actually tried this out.

Andrew Kennan
  • 13,947
  • 3
  • 24
  • 33
  • 1
    What is Entity Framework going to do with the struct? Create a new table? Other than that unknown, I do like that this provides a bit more value safety. – Eric J. Feb 08 '12 at 17:13