Гайдар Магдануров - ASP.NET MVC Framework

NHibernate, как и другие ORM, использует для реализации доступа к данным мэппинг в виде XML-файла. Этот файл должен быть оформлен согласно схеме nhibernate-mapping.xsd, которая идет в комплекте поставки. По традиции названия всех таких файлов мэппинга формируются как class_name.hbm.xml. Такой файл может выглядеть примерно так:

namespace="MyNamespace" assembly="MyNamespace">

Здесь создается мэппинг класса Customerна таблицу Customersв базе данных, которая содержит ряд полей: customerId, name, phone, address. Для подключения к базе данных должен быть создан другой конфигурационный файл, похожий на этот:

NHibernate.Connection.DriverConnectionProvider

NHibernate.Driver.SqlClientDriver

NHibernate.Dialect.MsSql2005Dialect

Server=(local);

Initial Catalog=MyDatabase;

Integrated Security=SSPI;

assembly="MyNamespace" />

К сожалению, для NHibernate отсутствует встроенная автоматизация генерации отображаемого кода и модели данных, а также файлов конфигурации. Поэтому описание модели ложится на плечи разработчика. С одной стороны, это рутинные операции, которые машина сделает лучше, но с другой, такой подход предоставляет разработчику больший простор для реализации его идей. Впрочем, в Интернете есть проекты с открытым исходным кодом, призванные облегчить и этот и другие процессы при работе с NHibernate:

□ Fluent NHibernate (http://fluentNHibernate.org/);

□ MyGeneration (http://www.mygenerationsoftware.com/portal/default.aspx);

□ NHibernate 1.2 Generator (http://gennit.com/);

□ NHibernate Query Generator

(http://ayende.com/projects/downloads/NHibernate-query-generator.aspx);

□ NHibernate Entity Generator (http://www.softpedia.com/get/Programming/Other-Programming-Files/NHibernate-Entity-Generator.shtml);

□ NHibernate Helper Kit (http://www.codeproject.com/KB/dotnet/NHibernate_Helper_Kit.aspx);

□ многие другие (http://stackoverflow.com/questions/41752/nhibernate-generators).

Для работы с 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 (https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/). Эта возможность позволит оперировать NHibernate-объектами в привычном для LINQ-разработчиков стиле и, наверняка, увеличит привлекательность библиотеки.

Очевидно, что чем ниже уровень абстракции механизма доступа к данным, тем выше его производительность. Несмотря на это, оценивать подходы только по скорости доступа к данным было бы неверно. При разработке приложений по работе с данными, особенно в больших проектах, в расчет должны приниматься, кроме всего прочего, и такие параметры, как:

□ удобство и единообразие доступа к данным;

□ объем кода, который может стать источником ошибок;

□ наличие инструментария для более быстрого и оперативного внесения изменений в структуру механизма доступа к данным.

И, хотя понятие простоты субъективно, все же мы можем попытаться оценить описанные технологии по простоте работы:

□ на первом месте LINQ для SQL, как простой, но все-таки эффективный Framework для отображения структуры базы данных на код;

□ NHibemate и Entity Framework на втором месте по простоте, как механизмы схожие во многом с LINQ для SQL, но все-таки в силу своей комплексности и обширным возможностям более сложны при построении слоя доступа к данным;

□ более сложным вариантом построения механизма доступа к данным является использование ADO.NET либо других методов, вроде прямого доступа к XML-файлам. Этот вариант требует поддержки большого объема самописного кода, большого внимания к его написанию, он потенциально более незащищен в связи с возможными уязвимостями.

Используйте низкоуровневые механизмы, вроде ADO.NET, в тех проектах, где скорость доступа к данным — это основная задача, и главное требование к проекту — высокая производительность. Для проектов, ориентированных на SQL Server, которые не предполагают высоконагруженной работы с данными или не содержат сложной структуры базы данных, вполне возможно использовать LINQ для SQL. В случае, когда простоты LINQ для SQL не хватает, либо используется база данных, отличная от SQL Server, хорошим решением станет один из ORM Entity Framework или NHibernate, в зависимости от ваших пристрастий и предпочтений.

Какой бы механизм вы не выбрали, основными принципами организации слоя доступа к данным должны оставаться слабая связанность с бизнеслогикой и возможность безболезненной замены этого слоя.

В паттерне MVC контроллеры выполняют следующие последовательные функции:

□ контроллер реагирует на действия клиента, например: нажатие кнопки отправки формы на сервер, Ajax-запросы, которые генерирует браузер, и др.;

□ контроллер оперирует с моделью, изменяя ее состояние;

□ контроллер выбирает представление, которому передает модель данных, тем самым представление формируется контроллером и отображается пользователю либо передается в виде набора данных клиентскому программному обеспечению.