Entity framework contains mapping functionality for entities, complex types and mapping integer columns to enumerations (only when .NET Framework 4.5 Beta and VS 11 is used). Is it enough? I don't think so and because of that I started a new suggestion on Data UserVoice: Support for simpe type mapping or mapped type conversions.
Sometimes we need to map (convert) values for simple types as well. This need for simple type mapping will become much more significant once we try to use Entity Framework with legacy database (or simply database which is not created primarily for Entity Framework). Perhaps these examples can sound familiar:
- Char column containing values y and n or VarChar column containing values yes and no or true and false - we want to map it to a boolean property
- VarChar column containing date - we want to map it to a DateTime or DateTimeOffset property
- VarChar column containing numeric value - we want to map it to a numeric type property
- VarChar column containing enum value - we want to map it to an enum property
But there can be more advanced cases:
- VarChar column containing joined values - we want to map to a list of strings
- VarChar column containing XML - we want to map to XElement or XmlDocument
- VarChar column containing some identification - we want to map it to a type defined by this identification (for example create CultureInfo from a string like en-us)
- Binary data which we want to map to a stream or a specific type
- As the most advanced case we can even think about using multiple columns to get a single property of some specific type (I don't mean mapped complex type in this case)
At the moment this can be achieved only with a workaround in mapped entities where we map the column to the property with the type demanded by Entity Framework and in the same time we expose the second non mapped property doing our conversion internally from the mapped one. That works for .NET code but it has several issues:
- It is mapping logic = it doesn't belong to the entity. The entity should not need to know anything about the way how it is persisted.
- It doesn't work if we want to use our new non mapped property for example for filtering in Linq-To-Entities queries. Linq-to-entities queries must use the original mapped property but it means that our mapping logic will even leave the entity and creep into other parts of our code.
- If Linq-to-entities need to use the mapped property, the property must also be accessible to the code defining the query. It usually means ugly public interface of our entity.
If you feel that this would be a valuable feature in Entity Framework, don't forget to vote for the suggestion on UserVoice because upcoming features in Entity Framework are currently selected only from highly voted suggestions.