I recently added 7 views to a database. When I go to may project that contains the data models for that db and use Reverse Engineer Code First (in EF 4.3.1) several views are not generated.
At first I thought there was some sort of order issue where a few of the views which depended on other views were somehow out of order and might be impacting the process. I renamed my views so that in the SQL Server Management Studio they appeared alphabetically in order they are needed.
This did not seem to help.
The 5 views which are generated are indeed the first 5 views that need to be there. However, the final 2 views are the ones not being generated.
All the views except for the first 3 contain joins on other views so I don’t expect joins to be an issue.
However, it looks as though both the missing views contain aggregates (SUM and appropriate GROUP BY functions) whereas the first 5 don’t.
I’ve done some searches but I don’t see anywhere that there is a restriction on aggregate functions in regards to Reverse Engineer Code First. Is there a workaround to this issue?
Update:
I made a new project and, instead of using my own convoluted existing database, I tried using Adventureworks. When I reverse engineered it the view with aggregates did indeed get modeled properly by EF.
When I looked at this view (Sales.vSalesPersonSalesByFiscalYears) I noticed that the all the aggregates were done using pivot. So I then rewrote my views that use aggregates to use pivots instead. They still do not get imported.
There is some strange key detection logic in the reverse engineer code that I don’t fully understand. It could simply be that an entity key could not be detected for those views.
In a separate project, try reverse engineering using database-first. The reverse engineer logic is the same, and it might give you more insight into why the views couldn’t be mapped.
If all else fails, you can always manually create Code First classes that map to those views. The msdn.com/data/ef site has some good articles on Code First’s default conventions, as well as the data annotations and fluent APIs (for properties and types or relationships) that can be used to map POCO classes to a database.