Our Solution is currently based on Entity Framework Database First. We have a T4 Template that generates repository classes from the EDMX.
We are reviewing our planned approach for releasing changes, especially Database changes. If we continue with Database first, then we will need to separately generate scripts to change the development and other databases.
It seems that with Code First, we simply change the model and that generates scripts to change the various databases. This seems more straightforward, does not involve hand crafting scripting processes and lower risk.
So, if we make the switch, is it simply a case of:
- Moving the previously generated models from EDMX in our Entities
Project to (they're all currently in one Class File) to (preferably
separate) Class Files in a folder within the Entities Project
- Adjust the T4 Template to pick up the models from their new location
- No longer using the EDMX and Update from Database
- When we want to make a change to the model, simply changing the (previously but no longer generated) classes
- Using Code First Migrations to implement changes to the Test and
other databases
Finally how would we see the relationships between the models? Is there a way of creating the diagram?
Thanks,
Chris
This is something I have done in the past. Over time I have tried many different methods. Currently I am using EF Reverse Poco Generator to allow changes to be made to the database and reflected in code and to initially generate the Model/Poco classes. I can also make changes to the existing classes manually. Then I generate migrations for each change.
The code-first model allows for the defining of navigation properties the same as you have now, so you can see the relationships through code and tools for visualizing class relationships.
If you want to see the database structure you can use the 'Database Diagrams' feature in MS Sql if that is what you are using. It is my impression that you are encouraged to use tools other than entity framework itself for visualizing database or class relationships. This allows the EF team to focus on Database code instead of complex UI integration with VS.
I personally I depend on Database Diagrams to check my class structure and the DB they output, but I find it natural to just look at the Poco classes. I haven't found any exceptional class diagramming tools.
All that being said, you are correct in your statements. Although I would start from the EF Reverse Poco generated classes from your existing db to give you that added flexibility. Point your T4 at those classes using reflection instead of XML parsing (Look at T4 Toolbox for output file management) to get you started.
Reflecting on assemblies is a sticky bit when you get started. You need to make sure you have the EF/Poco assembly compiled so it can be loaded in memory and reflected on by your T4. On rare occasions, depending on how you are loading the assembly, it can stop refreshing the assembly so you have to restart VS. I run across this a couple times a month, so it wasn't a deal breaker for me. Once I got it up and running it made sense.
