Support interfaces as entity and complex types
It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any algorithm against your data.
I am not sure this idea will be implemented one day. If it is then I have many other ideas to enhance its usage...
please support dbset<interface>...
Terry Coatta commented
I agree. It makes unit testing more challenging when one is forced to expose the concrete classes used in the data layer. In particular, I would like to be able to declare a DbSet<interface> and then provide a code first indication of the concrete type being mapped. This would mean that DbSet<interface>.AsQuerable() would have type IQueryable<interface> which is much easier to deal with when you are using a mocking framework.