NHibernate: значение по умолчанию для свойства над пустым столбцом

Question

Я работаю со старой базой данных, используемой другими приложениями, поэтому не могу изменить ее структуру.Иногда у меня есть обнуляемые столбцы, которые я хочу отобразить как ненулевой тип.Например, у меня есть столбец EndValidity со значением NULL в базе данных, который я хочу сопоставить с ненулевым DateTime, и, если он нулевой, это должен быть DateTime.MaxValue, или, как более простой пример, битовый столбец NULL, который должен иметь значение false, если ноль.

Я подумываю о том, чтобы написать для него пользовательский тип (с параметрами, если это возможно), или в него включено что-то для nHibernate?

Если единственное решение - написатьпользовательский тип пользователя, для логического случая, могу ли я переопределить соглашения fluentnhibernate, чтобы всегда применять этот тип пользователя для логических значений?

Answer 1

Это, вероятно, зависит от того, как вы хотите, чтобы ваш класс Poco вы действовали. Во-первых, если вы загружаете нулевое значение, хотите ли вы, чтобы нулевое значение было повторно сохранено, или вы хотите, чтобы какой-либо сеансовый коммит / сброс обновлял запись новым значением по умолчанию для пустого поля. Если вы хотите сохранить нулевое значение в БД, как вы будете определять из вашего объекта poco только логическое значение, значение которого для сохранения логических значений IE имеет только значения true / false, но ваш битовый класс имеет значения / значения null, 0 и 1?

Если сказать: вы хотите, чтобы ваши биты со значением NULL в качестве логического значения, а не NULL в логическом типе данных в вашем классе Poco, и класс обновили БД, чтобы удалить все нули, а затем одно решение, которое довольно быстро, без погружения в пользовательские типы должен иметь два свойства, одно обнуляемое и защищенное или внутреннее, и одно свойство в интерфейсе (без какого-либо отображения) с базовой логикой - из соображений зависимости все классы poco в идеале должны иметь один или два интерфейса: EG

internal virtual bool? isActive {get;set;}
public bool MyInterface.IsActive 
{
    get{ return isActive ?? false; }
    set{ isActive == value ?? false; };
}

Таким образом, ваша логика содержится в коде, поэтому, если правила становятся более сложными / сложными, или один обнуляемый бит имеет значение по умолчанию false, а другой имеет значение по умолчанию true (из-за какого-то безумного разработчика из прошлого века), вам будет проще контролировать преобразования. Это потребует от вас работы с интерфейсами, а не с настоящими классами poco, но, опять же, это не плохо, это просто зависит от вашей модели разработки.