Is it possible to use Entity Framework and a Database project together?

Question

At a conference yesterday, I learned about the importance of putting your database in source control. They showed us how to make a new Database project and import the database.

What I was wondering about is how I would change an existing project running on Entity Framework to utilize the database project's power? Schema updates have always been done by using Entity Framework Migrations. I get that the Database project will be able to deploy database updates for me and save those update scripts to source control, but I would like to keep Entity Framework for querying my data (if that makes any sense at all).

Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project in Visual Studio ? How do you go about this?

I've tried searching for similar questions and using Google to find if anyone else is having the same problem, but no dice so far.

I should also state that I am considering using this in databases that also have stored procedures in them. These are not controlled through Entity Framework at all, and therefore are not in source control yet.

Thank you for your time.

Answer 1

I just came across the below alternative, which I didn't test though:

Generate Entity Framework Core classes from a SQL Server database project - .dacpac file

I believe this should be something to be considered

Answer 2

What I was wondering about is how I would change an existing project running on Entity Framework to utilize the database project's power?

Answer: I suggest you to see this course from Plural Sight : https://www.pluralsight.com/courses/code-first-entity-framework-legacy-databases

Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project in Visual Studio ? How do you go about this?

Answer: Yes, it's possible and recommended. Your data project becomes the source of truth about the structure of your database. This is very powerful to keep control of all the changes and state of your database in one place (Visual Studio). The course from the first answer will teach you how.

I should also state that I am considering using this in databases that also have stored procedures in them. These are not controlled through Entity Framework at all, and therefore are not in source control yet.

Answer: I don't see any problem using stored procedures. The tool from the Plural Sight course will create the procedure in your source control and the reverse engineering will create a class/method for easy use of the proc.

Answer 3

I developed an application like that, having 2 projects: application itself and the SSDT project for the database. The database changes were deployed via change scripts, and EF migrations were disabled in the application.

Everything worked fine, although it did bring a bit of an overhead. For example, it was a bit of a hassle to introduce major database updates / refactorings into the EF layer. For some reason, I was unable to reverse engineer database changes directly into the app, so I had to do it half-manually: creating new project, generate EF context for the entire database, and then copying new / changed files into the main application.

(Then again, it was almost 5 years ago. With luck, EF scaffolding has improved since then.)