Шрифт:
</property>
<property name="connection.connection_string">
Server=(local);
Initial Catalog=MyDatabase;
Integrated Security=SSPI;
</property>
<mapping resource="MyNamespace.Customer.hbm.xml"
assembly="MyNamespace" />
</session-factory>
</hibernate-configuration>
К сожалению, для NHibernate отсутствует встроенная автоматизация генерации отображаемого кода и модели данных, а также файлов конфигурации. Поэтому описание модели ложится на плечи разработчика. С одной стороны, это рутинные операции, которые машина сделает лучше, но с другой, такой подход предоставляет разработчику больший простор для реализации его идей. Впрочем, в Интернете есть проекты с открытым исходным кодом, призванные облегчить и этот и другие процессы при работе с NHibernate:
? Fluent NHibernate ;
? MyGeneration ;
? NHibernate 1.2 Generator ;
? NHibernate Query Generator
;
? NHibernate Entity Generator ;
? NHibernate Helper Kit ;
? многие другие .
Для работы с NHibernate используются пространства имен NHibernate и NHibernate.Cfg. Второе служит для загрузки файла конфигурации, например, как показано в следующем примере:
ISessionFactory sessionFactory = new Configuration
.Configure("Nhibernate.cfg.xml").BuildSessionFactory;
где Nhibernate.cfg.xml — ваш файл конфигурации.
NHibernate основывается на объектах ISession, которые представляют собой пользовательскую сессию подключения к базе данных, поэтому для работы с данными необходимо создать экземпляр ISession. В качестве примера работы с NHibernate можно привести такой шаблон кода:
ISession session;
ITransaction tran;
try
{
session = sessionFactory.OpenSession;
tran = session.BeginTransaction;
// делаем какую-то работу
tran.Commit;
session.Close;
}
catch (Exception ex)
{
tran.Rollback;
session.Close;
}
Как вы можете заметить, NHibernate реализует механизм транзакций с возможностью откатывать ненужные изменения.
Работа с объектами NHibernate возможна с помощью одного из трех вариантов:
? Hibernate Query Language (HQL) — языка во многом похожего на язык LINQ c SQL-синтаксисом;
? Query By Criteria (QBC) — объектный вариант, который позволяет строить выражения запросов динамически через объектно-ориентированный API;
? через обыкновенные SQL-запросы.
Приведем простой пример использования HQL:
string result = (string)session.createQuery(@"select phone
from Customer as c
where c.name = 'Сергей Иванов'").UniqueResult;
Пример вернет телефон заказчика по его имени. Перепишем этот пример с использованием Query By Criteria:
ICriteria crit = session.CreateCriteria(typeof(Customer));
crit.Add(Expression.Eq("name", "Сергей Иванов"));
crit.SetMaxResults(1);
string phone = (string) crit.UniqueResult;
Как можно убедиться, эти варианты отличает одно важное свойство — динамическое построение запроса, которое может найти применение в ряде случаев, например, при фильтрации сложного по структуре массива данных.
Кроме того, в будущих версиях NHibernate может появиться полноценная поддержка LINQ. По крайней мере, частичная реализация уже существует в NHibernate Contrib . Эта возможность позволит оперировать NHibernate-объектами в привычном для LINQ-разработчиков стиле и, наверняка, увеличит привлекательность библиотеки.
Сравнение механизмов доступа к данным
Очевидно, что чем ниже уровень абстракции механизма доступа к данным, тем выше его производительность. Несмотря на это, оценивать подходы только по скорости доступа к данным было бы неверно. При разработке приложений по работе с данными, особенно в больших проектах, в расчет должны приниматься, кроме всего прочего, и такие параметры, как:
? удобство и единообразие доступа к данным;
? объем кода, который может стать источником ошибок;
? наличие инструментария для более быстрого и оперативного внесения изменений в структуру механизма доступа к данным.
И, хотя понятие простоты субъективно, все же мы можем попытаться оценить описанные технологии по простоте работы:
? на первом месте LINQ для SQL, как простой, но все-таки эффективный Framework для отображения структуры базы данных на код;
? NHibemate и Entity Framework на втором месте по простоте, как механизмы схожие во многом с LINQ для SQL, но все-таки в силу своей комплексности и обширным возможностям более сложны при построении слоя доступа к данным;