When using EF, and in particular Code First, people's expectations are naturally that we will be able to map almost anything they can put in their object model, when the reality is that the constructs and shapes that we can map are quite constrained, e.g.:
1. Entity types need to have parameter-less constructors (no support for other constructors, factory methods, immutable types, etc.)
2. We only support scalar properties (as opposed to fields) of a reduced subset of primitive types
3. Those scalar properties can only be mapped to columns of compatible types in the database (i.e. custom types and type conversions in mapping are not supported)
4. Only simple collections (as opposed to dictionaries, other collection constructs or IEnumerable properties with separate Add/Remove metods) of entity types are supported (i.e. collections of scalar and complex types are not supported)
5. Collection ordering is ignored
6. All entity types need to have primary keys, even if they are contained
7. Although foreign keys are not mandatory the behavior of independent associations is not as predictable and nice as the behavior of associations with foreign keys
8. Inheritance is not supported in complex types
9. Navigation properties are not supported in complex types
10. Complex types are not supported as keys
12. Entity and complex types cannot be generic
13. Lazy loading can only be performed on navigation properties
14. Etc.
In the future there are different ways we can improve EF to support many more scenarios:
1. Extending C-S mapping it should be possible to support at least some of the more complex shapes mentioned above
2. Through a combination of flexible O-C mapping, type conversions and shadow state it should be possible to infer a conceptual model and a database schema for almost any arbitrary shape of an object model, e.g. EF could map columns to fields with or without a property present, also a collection of string properties could be mapped to an entity type containing a key and a string property, then map this entity to the elements of this List<string> so that the string property is stored as the string instances and the key is kept in shadow state and/or mapped to the ordering of the elements in the list, also complex types with inheritance could be mapped to entity types with keys in shadow state, also dictionary properties could be mapped to entity types where they dictionary key is the key of the entity, etc.
3. We could add the ability to EF to fall back to serializing non-recognizable properties or even whole object shapes as blobs in the database. This option represents an important departure from the current assumption in EF that we shred objects into separate columns and only persist things that we know how to query for later. In other words, in the current design of EF we assign the same priority to queryability and to persistability. In this design we would prioritize persistability over queryability.
There are some other issues that track specific scenarios to enable:
* http://entityframework.codeplex.com/workitem/801
* http://entityframework.codeplex.com/workitem/664
Comments: Personally, I really need possiblity of mapping each db column to custom class directly. It should be also posible for table key(s). See http://stackoverflow.com/questions/5126146/bind-custom-class-to-a-column-in-database-with-ef-4-poco
1. Entity types need to have parameter-less constructors (no support for other constructors, factory methods, immutable types, etc.)
2. We only support scalar properties (as opposed to fields) of a reduced subset of primitive types
3. Those scalar properties can only be mapped to columns of compatible types in the database (i.e. custom types and type conversions in mapping are not supported)
4. Only simple collections (as opposed to dictionaries, other collection constructs or IEnumerable properties with separate Add/Remove metods) of entity types are supported (i.e. collections of scalar and complex types are not supported)
5. Collection ordering is ignored
6. All entity types need to have primary keys, even if they are contained
7. Although foreign keys are not mandatory the behavior of independent associations is not as predictable and nice as the behavior of associations with foreign keys
8. Inheritance is not supported in complex types
9. Navigation properties are not supported in complex types
10. Complex types are not supported as keys
12. Entity and complex types cannot be generic
13. Lazy loading can only be performed on navigation properties
14. Etc.
In the future there are different ways we can improve EF to support many more scenarios:
1. Extending C-S mapping it should be possible to support at least some of the more complex shapes mentioned above
2. Through a combination of flexible O-C mapping, type conversions and shadow state it should be possible to infer a conceptual model and a database schema for almost any arbitrary shape of an object model, e.g. EF could map columns to fields with or without a property present, also a collection of string properties could be mapped to an entity type containing a key and a string property, then map this entity to the elements of this List<string> so that the string property is stored as the string instances and the key is kept in shadow state and/or mapped to the ordering of the elements in the list, also complex types with inheritance could be mapped to entity types with keys in shadow state, also dictionary properties could be mapped to entity types where they dictionary key is the key of the entity, etc.
3. We could add the ability to EF to fall back to serializing non-recognizable properties or even whole object shapes as blobs in the database. This option represents an important departure from the current assumption in EF that we shred objects into separate columns and only persist things that we know how to query for later. In other words, in the current design of EF we assign the same priority to queryability and to persistability. In this design we would prioritize persistability over queryability.
There are some other issues that track specific scenarios to enable:
* http://entityframework.codeplex.com/workitem/801
* http://entityframework.codeplex.com/workitem/664
Comments: Personally, I really need possiblity of mapping each db column to custom class directly. It should be also posible for table key(s). See http://stackoverflow.com/questions/5126146/bind-custom-class-to-a-column-in-database-with-ef-4-poco