FluentNHibernate Table DataTypes (разные поставщики баз данных) - PullRequest
Новая
       7

FluentNHibernate Table DataTypes (разные поставщики баз данных)

1 голос
/ 30 декабря 2010

У нас есть ситуация, когда нашей производственной базой данных является Firebird, но мы хотели бы провести внутреннее тестирование интеграции с использованием SQLite. Пока что единственные проблемы, с которыми мы сталкиваемся, - это различия в типах данных, используемых обеими базами данных.

Например, когда мы отображаем каждый объект домена с помощью FluentNHibernate, мы указываем тип столбца всякий раз, когда нам нужно явно указать его. Мы указываем CustomSqlType, используя свойство из следующего класса; 

public static class DATATYPES
{
    public const string SMALLINT = "SMALLINT";
    public const string BOOLEAN = "CHAR(5)";
    public const string INTEGER = "INTEGER";
    public const string DECIMAL_MONEY = "DECIMAL(18,4)";
    public const string DECIMAL_EXCHANGE_RATE = "DECIMAL(18,8)";
    public const string DECIMAL_QUOTE_PRECISION = "DECIMAL(7,6)";
    public const string DECIMAL_PERCENT = "DECIMAL(6,2)";
    public const string BLOB_NULLABLE = "BLOB SUB_TYPE 1 SEGMENT SIZE 1 CHARACTER SET UTF8 COLLATE UTF8";
    public const string BLOB_NOTNULL = "BLOB SUB_TYPE 1 SEGMENT SIZE 1 CHARACTER SET UTF8 NOT NULL COLLATE UTF8";
}

Из приведенного выше класса видно, что мы сопоставляем логические значения со столбцом CHAR (5) в базе данных Firebird. Теперь, когда мы пытаемся использовать то же отображение для SQLite, мы сталкиваемся с проблемами для полей BLOB и Boolean.

Мне бы хотелось получить несколько советов о том, что мы можем сделать, чтобы преодолеть этот недостаток, не дублируя код отображения для разных баз данных.

1 Ответ

0 голосов
/ 30 декабря 2010

Сверху моей головы, вместо того, чтобы явно определять тип столбца в каждой точке, в которой вы сопоставляете свойство с полем, вы могли бы вместо этого объединить это в условный класс, на который вы бы указали?Это было бы полезно в любом случае (если бы каждое логическое значение было сопоставлено с CHAR (5), соглашение было бы лучше, чем индивидуальное сопоставление его для каждого логического свойства в любом случае).Тогда вы могли бы просто переключать соглашения в зависимости от используемой БД.

...