3

We are working on a project that uses Entity Framework 4 (code-first) and Fluent Migrator.

In going throughout the project, we've created migrations for all of our schema changes and profiles for test-data that we want populated in our various environments.

However, what is the best practice for inserting "codes" and/or "statuses" that we want populated in all of our environments? Should we specify them during the creation of the tables or should we create a specific profile for them?

To be more specific, we have a "code" table for Address Types defined for our database like so:

[Migration(22)]
public class M0022_CreateAddressTypesTable : Migration
{
    public override void Up()
    {
        Create.Table("AddressTypes")
            .WithColumn("Id").AsInt32().NotNullable().PrimaryKey()
            .WithColumn("Name").AsString(50).NotNullable().WithDefaultValue(string.Empty)
            .WithColumn("Description").AsString(100).NotNullable().WithDefaultValue(string.Empty);
    }

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

So, should we use this chance to also populate the AddressTypes table with our data? Or should we abstract that away into a profile of some sort?

I see benefits and disadvantages of both, so I'd love to hear how other teams are handling this type of situation.

Jeffrey Harrington
  • 1,797
  • 1
  • 15
  • 24

1 Answers1

2

I would personnally put "Reference datas" in the migration class, not a profile one, if you are sure you need them for all environments.

Maintenance & code comprehension are always easier with simple rules, like :

Profile => specific (test, other) datas

Migration => generic datas

A specific profile would only add useless complexity (my humble point of view).

Raphaël Althaus
  • 59,727
  • 6
  • 96
  • 122
  • 1
    I still go back and forth. For instance, to see where codes and/or status values are added, you'll have to scan through almost all of your migration files. If they were in a single file, they'd be in one place and easier to manage. I think that actually improves maintenance and code comprehension. – Jeffrey Harrington Mar 13 '12 at 14:38
  • Well, then why don't you just create a single static class with "insert methods", that you can call from your different migration classes. You can't add datas for tables that don't exist, so you have "concrete insertions" in one place, and calls to these insertions where you need them – Raphaël Althaus Mar 15 '12 at 20:16