Как я могу остановить nHibernate от полезной установки значения даты в ненулевом поле объекта, когда базовое значение поля базы данных равно null?

Я с волнением прочитал первую попавшуюся статью в гугле — это была как раз моя проблема. У меня есть объектная модель с ненулевым полем даты, но базовое поле базы данных допускало значение NULL и имело нулевое значение. Это был DateTime. nHibernate установил значение .Net Date.MinValue, а затем попытался сохранить его обратно, что привело к ошибке.

Решение в статье: Просто используйте «DateTime?» в доменной модели.

Это не сработает для нас.

Вот в чем дело: мы проводим серьезный рефакторинг, который включает миграцию данных из одной схемы в другую, переход от ADO к nHibernate и т. д., сложные вещи. Итог: объектная модель верна как есть, это НЕ значение DateTime, допускающее значение NULL («CreatedDate»). Установить его на DateTime? технически будет работать, но это неправильно доменно. Чего я ДЕЙСТВИТЕЛЬНО хочу, так это того, чтобы nHibernate перестал быть таким полезным и просто выдавал ошибку, когда он сталкивается с попыткой загрузить нулевое значение DateTime в ненулевой объект домена. Я считаю, что это поможет нам гораздо быстрее выявить эти проблемы.

Я знаю, что nHibernate легко настраивается/сопоставляется... есть ли способ добиться такого поведения и как лучше всего это сделать...?

Заранее благодарю за любую помощь!


.net nullable datetime nhibernate
person Edward Buatois    schedule 22.02.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Является ли DateTime.MinValue полезным значением для вас?

Разве вы не можете просто реализовать установщик и выдать исключение, когда получите это значение?

person Lasse V. Karlsen    schedule 23.02.2010

arrow_upward
0
arrow_downward

Похоже, что сам столбец на самом деле не должен иметь значение NULL в базе данных. Одна вещь, которую я видел в прошлом, - это по умолчанию для столбца «CreateDate» значение getdate() в базе данных. Вы также можете реализовать триггер для установки CreateDate в getdate() при вставке записи. Если вы используете значение по умолчанию, значение будет установлено при вставке записи (если вы не передадите ее явно), и Hibernate сможет вернуть ее вам после сохранения или при следующем поиске. запись.

person Andy White    schedule 22.02.2010
comment
Спасибо за быстрый ответ, Энди. Я согласен с тем, что правильное решение состоит в том, чтобы сделать эти поля базы данных необнуляемыми. Дело в том, что мы проводим серьезный рефакторинг большой базы данных, и, похоже, мы сделали несколько полей обнуляемыми, чего не должно быть. Я надеялся, что получение nHibernate для выдачи ошибки в случае несоответствия с нулевым/ненулевым значением, подобного этому, поможет нам определить поля, которые мы пропустили. - person Edward Buatois; 23.02.2010

arrow_upward
0
arrow_downward

Лучшее решение — сделать поле в базе данных необнуляемым. Есть ли причина, по которой вы не можете этого сделать? Важно, чтобы допустимость значений NULL в вашей модели предметной области соответствовала схеме базы данных.

Я не знаю, как настроить это поведение с помощью конфигурации. Если это влияет на несколько полей, вы можете скрыть проблему, сопоставив приватное поле и управляя им через свойство, но это не даст вам исключения при загрузке. Для этого вам нужно написать реализацию ILoadEventListener (я думаю, что это правильно, я никогда этого не делал).

person Jamie Ide    schedule 23.02.2010