I have a custom DatabaseInitialiser which is below
///
/// Implements the IDatabaseInitializer to provide a custom database initialisation fo
To summarise,
1) what is the correct use-case for the different techniques available ? 2) what would be the ideal strategy so that the migrations work in all conditions and when we move databases from one environment to another ?
Step back and ask yourself when you would want EF to do the initializations and migrations. In my (enterprise) organization, we have very strict rules about how code, data and DDL is migrated, so these features offer us no value. Even if we could use them, I would be very wary until I had quite a lot of experience with the tool in different environments.
So, why use it? You're starting a new green field project and are using code-first. Now, here is where it is useful. You can write your code, compile, run, and let EF worry about the new or missing fields, relationships, and tables. Later, you can formalize it in your development server, then remove the initializers and migraters forever more.
As for how to set it up? It sounds like you found a way that works. I agree it seems a bit hacky, but the code is similar to my initial setup. I am using MVC.NET, so I used the following in Global.asax.cs:
Database.SetInitializer(new DomainInitializer());
Bottom line is I think your (2) is the wrong question. It should be, "do I really want to do it this way?". It might turn out that you do, but I'd consider other more traditional options first, especially if you're in a company larger than 10 people.