Мои личные "часто объясняемые" проблемы:
Антишаблоны
Возиться с отделенными объектами (SaveOrUpdate или Merge плюс немного грязного кода) вместо использования DTO. Чем сложнее сущности, тем сложнее код. (Это также означает, что он довольно хорошо работает с тривиальными объектами.) Айенде также называет это « Стриппер» и объясняет проблему инкапсуляции.
Непонимание постоянного невежества и написания приложений NH, как при использовании явного SQL. Симптом этого: вызов Update после изменения объекта, недоумение, почему изменения сохраняются, даже если Update не было вызвано, недоумение, как избежать сохранения изменений.
Непонимание транзакций и единицы работы . Частые анти-паттерны: неявные транзакции, сеанс на операцию и сеанс на приложение. Еще немного чтения:
Использование событий NH для добавления логики приложения (например, отслеживание изменений в триггерах вставки и обновления)
Создайте один класс на таблицу . Некоторые люди не понимают OOD, другие не понимают реляционный дизайн.
Ошибки
использование одного к одному вместо многих к одному. Я пытался это объяснить в этом ответе .
Использование объединения в сочетании с SetMaxResult. Мои последние ответы, связанные с этой темой:
Написание самоизменяющихся объектов . Когда сущность не возвращает точно значение, которое было установлено NH, она считается грязной и обновляется в каждом сеансе. Например: замена постоянной коллекции NH в установщике свойств.
IList<Address> Addresses
{
get { return addresses; }
// will cause the addresses collection to be built up from scratch
// in the database in every session, even when just reading the entity.
set { addresses = new List<Address>(value); }
}
int Whatever
{
// will make the entity dirty after reading negative values from the db.
// this causes unexpected updates after just reading the entity.
get { if (whatever < 0) return 0; }
set { whatever = value; }
}
Может быть, больше следит.