Improve Database First Support
Code First is no match for real life situations and also Proxies create lot of runtime problems.
We use Dictionary<Type,object> to store Lambda Expressions that are designed to act as Filters for one type. Here is the problem, at runtime code first entity type is a dynamic type leading to following problems.
1. Dynamic Type implementation is hidden.
2. It does not support INotifyPropertyChanged
3. It does not allow us to inspect/validate property with partial methods which we were able to do with Database First (EDMX) Model.
4. CreateSourceQuery is hidden, sometimes we want to only execute Any or inspect further Where or use CreateSourceQuery as subquery in other linq operation. In case of Collection navigation property I assume that it will not hit database untill we enumerate over it. But what about singluar navigation property? We need IEntityReference and we need CreateSourceQuery to create subqueries.
5.We already have code base where we inspect Entity Scalar Member attribute to identify primary key etc, we need them to build linq dynamically at runtime. Code First hides everything and becomes more pain.
6. Biggest problem is initialization of DbContext, from my understanding DbContext creates each of DbSets, though it does not connect to database, creation is delayed, where in ObjectContext ObjectSet would create only if we access it.
7. If proxies generated at runtime would do exactly same as Entity Object would behave, then why not still derive entities from EntityObject and improve certain performance. Recreating proxies at runtime wouldn't hurt performance?
8. It is better to use text template to generate everything at designtime. Runtime classes makes debugging a huge nightmare. Reflection breaks as well.
9. Code First is useless in multi app with single database scenario. We work on large application, where multiple teams work on single production database and we only have access to schema as there is centralized control over schema of database. We have to push our database changes to DB admin who then integrates changes from all teams and put in database. Automatic upgrades won't work.
John Alexander Zabroski commented
This is a pretty confusing list of suggestions, but, unbundled, it sounds like you have boxed yourself into a difficult design flaw: your filters are stored on entities rather than a higher level of search results.
It sounds like you are asking for features to solve your modularity issues due to tight coupling in your app. Can you provide more info?