Are protected entity properties in EF 4 a bad idea with data services?

After some NullReferenceException headache from deep down System.Data.Services I found out that 开发者_JAVA百科data services doesn't like properties in the EF model marked as protected.

The exception occurs when the data service is initializing and tries to generate metadata for the EF model. Apparently Microsoft decided to throw a NullReferenceException when reflecting protected properties here rather than a meaningful message.

I use a few protected properties to wrap custom types not available in the database. This is a convenient way of representing for example enums in the database. The enum can be represented as a protected string property with a public enum wrapper that converts to and from the string value. This works very well in all other EF usage scenarios and I would rather not abandon the protected properties pattern.

I use self tracking entities that flows around nicely with WCF. Protected properties works well since I have checked "Reuse types in referenced assemblies", which makes my wrapper properties available in all assemblies. I was hoping that I could do something similar with a data service. I realize that I might run into trouble if I want to construct a query where the protected properties is part of the expression, but that is a different problem that could be addressed otherwise.

Is there a (practical) way to use protected entity properties with a data service?

If not, how should I best represent non-db types if I don't want to keep my set of public properties nice and clean?

Obviously I could just make everything public, but that would be a practice that rhymes with globals.

What about calling SetEntitySetAccessRule?