none
Controlling the Name of an Entity exposed via the Reflection Provider RRS feed

  • Question

  • I have the following classes defined:

        public abstract class Entity<TKey> : ICloneable
        {
            public TKey ID { get; set; }
            public virtual object Clone()
            {
                return this.MemberwiseClone();
            }
        }
        public class Person : Entity<String>
        {
            public string Name { get; set; }
        }
        public class PersonContext
        {
            List<Person> _people = new List<Person>()
            {
                new Person() { ID="A", Name="A1"},
                new Person() { ID="B", Name="B1"},
                new Person() { ID="C", Name="C1"},
                new Person() { ID="D", Name="D1"},
                new Person() { ID="E", Name="E1"},
                new Person() { ID="F", Name="F1"},
            };
            public IQueryable<Person> People
            {
                get { return _people.AsQueryable(); }
            }
        }

    When I expose Person via a dataservice, I get the name "Entity_x0060_1_x005B_System.String_x005D_" for the base class which does not meet the TSimpleIdentifier rules.

    Is there a way to control the nameing of the class?  I have tried marking it with DataContract like below and it does not change in the $metadata.

    [DataContract(Name = "{0}Entity")] public abstract class Entity<TKey> : ICloneable { [DataMember] public TKey ID { get; set; } public virtual object Clone() { return this.MemberwiseClone(); } }

    I am using the version of data services that shipped with .Net 4.0 and VS 2010. Any ideas?


    Tuesday, December 4, 2012 8:36 PM

Answers

  • Hi,

    This is a known issue and there's currently no workaround. The underlying problem is that EDM (the data model) does not support generics and thus there's no meaningful way how to represent your classes in the $metadata. And even if the naming could be fixed, client would still not know how to consume such a service correctly. As you've seen the Entity class would get define in the $metadata with one specific type for its generic parameters, so if you would use it for some other entity with a different type it would get defined again in the metadata (for that other type). In the end the inheritance chain would not carry over to the client which could cause lot of interesting misbehaviors/issues.

    So in effect generics in the model are not supported. But since this behavior already shipped by the time we found out about it, we could not really remove it. After all the service does not break on itself. It's when some spec compliant client wants to use when it breaks. So we decided to leave the functionality in there, but suggest for people not to use it.

    Thanks,


    Vitek Karas [MSFT]

    Wednesday, December 5, 2012 7:37 AM
    Moderator