NHibernate или быстрый NHibernate? [закрытый]
Вы могли настроить повторяющуюся функцию, которая контролирует состояние всей сетки и генерирует событие, которое указывает, допустима ли вся сетка или нет.
Ваш 'утверждают, что форма' кнопка тогда включила бы или отключила бы себя на основе того состояния.
, О, я вижу подобный ответ теперь - который работает также, конечно.
4 ответа
Fluent NHIbernate находится поверх NHibernate, поэтому на самом деле это не выбор между ними. Если вы собираетесь использовать NHibernate, ВЫБЕРИТЕ использование Fluent NH поверх него, чтобы сэкономить огромное количество усилий.
Fluent NHibernate - это здорово, я бы не стал использовать NHibernate без него. Вы можете легко отображать все свои сущности (обеспечивая проверку времени компиляции и поддержку автоматического тестирования) вместо того, чтобы поддерживать громоздкие XML-файлы и помнить их синтаксис / DTD.
Он также может автоматически отображать ваши сущности на основе значений по умолчанию и / или свои собственные соглашения.
Просто используйте это!
Преимущество использования Fluent NHibernate вместе с NHibernate заключается в том, что вы получаете ошибки времени компиляции, если вы испортили свое отображение, вместо ошибок времени выполнения. Вы также получаете гораздо лучший опыт при рефакторинге кода, поскольку ваши сопоставления обновляются при переименовании свойств или чего-то еще, вместо того, чтобы не забывать вручную изменять файлы сопоставления XML.
Самый большой недостаток Fluent NHibernate - это что он все еще находится на довольно ранней стадии своего развития, и существует довольно большой риск поломки изменений по мере развития инфраструктуры.
Лично я не особо разбирался в плавном спящем режиме, поскольку мне удобны файлы сопоставления. Использование Visual Studio для создания файлов сопоставления очень просто, и вы можете установить схему для файла xml, которая дает вам intellisense в файле сопоставления. Я согласен с тем, что проверка синтаксиса во время компиляции является преимуществом по сравнению с использованием fluent-nhibernate, но мне трудно оправдать изучение свободного API, когда я уже знаком с отображением XML. Возможно, мне стоит просто перебороть свою энергию и уже выучить ее ...: -)
Я бы определенно сказал, что буду использовать fluent-nhibernate. Просто имейте в виду, что поездка не обязательно будет такой гладкой, как вы надеялись.
Что касается зависимости версий
- У меня была проблема с «обратной» зависимостью, когда при обновлении до новой версии FNH мне требовалось перейти на новую версию NH (думаю, с 2.0 до 2.1). Для меня это не было большой проблемой.
- Я недавно (сегодня утром) сбросил NH 2.1.1 в FNH 1.0 RTM (он распространяется с 2.1. 0) без драм (пока).
Редактировать: С момента написания этого поста FNH существенно повзрослел до такой степени, что я не думаю, что это более серьезная проблема.
Поддержка сопоставления - некоторые сопоставления еще не возможны при беглом nhibernate. Однако это НЕ причина избегать FNH, поскольку гибридные сопоставления fluent-xml позволяют вам отказаться от традиционного xml в случае, если fluent не может сопоставить его (хотя это только на уровне детализации для каждого класса). Примеры сопоставлений:- Не удается сопоставить поля - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
- Не удается сопоставить несколько раз словаря http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - на самом деле, насколько я понимаю, эта функция существует, но еще не является основной.
Коэффициент сложности сложного соединения. По его звукам вы будете изучать и FNH, и NH одновременно. Для большинства довольно простых приложений это нормально - на самом деле FNH часто настолько хорош, что вам нужно довольно мало знать о сопоставлениях hbm.xml. Но если вы хотите заняться чем-то достаточно сложным, это редко срабатывает с первого раза, и вам остается только гадать, является ли это проблемой PEBKAC, fluent или NH. Чаще, чем я ожидал, мне приходилось писать традиционные сопоставления xml (конечно, вы все равно делаете это, но было бы предпочтительнее не тратить больше усилий, чем необходимо, сначала возясь с fluent).