Decouple entity creation in EF and support entities without default constructors and publically settable properties
EF should decouple the implementation of the entity objects from the mapping functionalities. The EF team could provide the current entity creation as a default variant which can be attached to the mapper. The developer has the option to provide it's own data transfer object layer. Therefore we need to abstract the entities through interface usage an a generic naming schema (dot notation of an object model like Person.Name). So the EF would be much more flexible to use.
Note by Diego Vega: I am merging this idea with a few other ideas that are approximately equivalent but extend in other directions:
- On one hand we could support materializing objects invoking constructors with parameters and non-publically settable properties. Another way to do it (popular in among users of other O/RMs) would be to support materializing to private fields. In addition, we could support registering factory methods or some other resolution mechanism like plugging in an IoC container.
- On one hand, support for materialization of objects with constructors with parameters could be transparent, e.g. the query db.Customers doesn't need to specify how each customer needs to be constructed. It just specifies that customers can be queried using this property. On the other hand, we could also allow explicitly constructing an object with a constructor with parameters in the outmost projection: db.Customers.Select(c => new ListItem(c.Id, c.Name)).
To be useful as persistence ignorant Domain Model objects, POCO Entities should be allowed to have no default constructor, but only constructors with parameters. Data should be exposed as read-only properties that would still be persistable to the database.
Adam Churvis commented
Requiring default constructors and publicly-accessible properties when using EF is my Public Enemy Number One. Parameterized constructors, definitely.
I hope this does not require me to have a DTO for each object in the Domain Model, though. I would like to store Domain Model objects directly with no DTO and be able to specify an IoC container to create entities.
Joshua Ramirez commented
We should be able to use an entity factory extension point, much like the controller factory in MVC3!
Tuomas Hietanen commented
This would be nice to have immutable classes and private setters
This is also needed in case you want to use an IoC container to create each entity!
Morten Mertner commented
I'm voting for this, but think Petr's description is worth reading also.
Alternatively, provide hooks that allow us to inject our own object materializer into EF to bypass the sad default constructor requirement.
Petr Kuzel commented
Petr Kuzel commented