Наилучшая практика для добавления кода и значений состояния с FluentMigrator? - PullRequest
Новая
       23

Наилучшая практика для добавления кода и значений состояния с FluentMigrator?

3 голосов
/ 01 марта 2012

Мы работаем над проектом, который использует Entity Framework 4 (сначала код) и Fluent Migrator.

В ходе всего проекта мы создали миграций для всех наших изменений схемы и профилей для тестовых данных, которые мы хотим заполнить в различных средах.

Однако, какова лучшая практика для вставки "кодов" и / или "статусов", которые мы хотим заполнить во всех наших средах?Должны ли мы указывать их при создании таблиц или мы должны создать для них определенный профиль?

Чтобы быть более точным, у нас есть таблица «кода» для типов адресов, определенных для нашей базы данных, например: 

[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");
    }
}

Итак, должны ли мы использовать эту возможность, чтобы также заполнить таблицу AddressTypes нашими данными?Или мы должны абстрагироваться от этого в какой-то профиль?

Я вижу преимущества и недостатки обоих, поэтому я хотел бы услышать, как другие команды справляются с такой ситуацией.

1 Ответ

2 голосов
/ 01 марта 2012

Я бы лично поместил «Справочные данные» в класс миграции, а не в профиль, если вы уверены, что они нужны для всех сред.

Обслуживание и понимание кода всегда проще с простыми правилами, такими как:

Профиль => конкретные (тестовые, другие) данные

Миграция => общие данные

Определенный профиль только добавит бесполезную сложность (моя скромная точка зрения).

...