Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Place to put Database.SetInitializer

I'm working on a project that at can end up with multiple UI versions / variants, but so far I've got two subprojects in my solution Web - containing Web interface with ASP.NET MVC. Service project is place where I have my database context and models defined.

My Goal is to have minimum or possibly no references to EF specific code in my Web project. I want it to be independent so when I switch the dlls with service backend ( from let say SQL to XML or MySQL ) I shouldn't make multiple modifications in my MVC project.

This is how it looks :

Project layout

My Questions are: - so far I've found no example of using Database.SetInitializer in other place than Global.asax. I'd like to put database re-creation if model changed in my factory-like DatabaseContextProvider class or in service class that pulls out data from context and provides it to the UI with DTOs. Are there any cons of that location ? - I would like to have the context's connectionString to be configurable with Properties/Settings.settings file - is that reasonable ?

like image 417
Paweł Staniec Avatar asked Dec 30 '11 12:12

Paweł Staniec


People also ask

What is the purpose of DropCreateDatabaseAlways database initializer in Entity Framework?

DropCreateDatabaseAlways: As the name suggests, this initializer drops an existing database every time you run the application, irrespective of whether your model classes have changed or not.

Which namespace contains the DB context class?

The by-convention name is the full name (namespace + class name) of the derived context class. See the class remarks for how this is used to create a connection. Constructs a new context instance using the existing connection to connect to a database.

Which of the following are database initialization strategies in EF Code First?

DropCreateDatabaseAlways: This strategy of code first approach creates the database every time you run the application. If the database already exists and there is no modification done in the model, it will drop the database and create a new one. In this approach, you will also lose the data.


Video Answer


2 Answers

To avoid the coupling, I would prefer not to set the initializer outside the Assembly that contains the DataContext. So, I added a static constructor for the DataContext. This way every project referencing this Assembly will enjoy the initializer without explicitly setting it, and the initializer is set only once per process.

static MyDataContext() {    Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDataContext, Configuration>()); } 

The connection string will of course be taken from the application configuration file.

like image 142
RonyK Avatar answered Oct 05 '22 09:10

RonyK


You would need a mechanism to call the Database.SetInitializer method before the very first usage of the DbContext. That is why its usually called in the Global.asax file.

You can create a class with an initialization method in your tm.Service project and call it in the Application_Start method and put the Database.SetInitializer in that initialization method.

Its OK to supply the connection string from a setting file.

like image 41
Eranga Avatar answered Oct 05 '22 10:10

Eranga