Is using Entity Framework code first purely for database migrations ok?

Question

I'm currently using RoundhousE to manage my database migrations and this works really nicely.

I have been looking into various migration creation technologies like FluentMigrator and some others. The possibility for errors though seems really high because most of them aren't strongly typed. For instance this is a migration from FluentMigrator

public class CreateMemberTable : Migration
{
    public override void Up()
    {
        Create.Table("Members")
            .WithNamedIdColumn("MemberId")
            .WithColumn("Name").AsString().NotNullable();
    }

    public override void Down()
    {
        Delete.Table("Members");
    }
}

I've used Entity Framework code-first before and really liked the migration engine in that it generates code based migrations then you can make any changes that you require afterwards. However I don't really need the rest of the EF framework, it's a bit heavyweight for what i'm looking for.

Would it be acceptable to just use EF for migrations but not bother with any of the rest of it? There's also a nice roundhouse plugin

Most of the data i'm using is flat to something like PetaPoco or Dapper seems like a lighter solution from an ORM standpoint.

Answer 1

I believe you can, but to do so you have to bring about the mapping pieces of EF. Because of that I'm not sure how much you would gain over not using EF in your code. But it's definitely possible, it's just tied to the mapping constructs and context.

One can also use RH (RoundhousE) RefreshDatabase with just SQL files if you want to go that route.