Чтение онлайн

</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, но все-таки в силу своей комплексности и обширным возможностям более сложны при построении слоя доступа к данным;

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

Рекомендации по выбору механизма доступа к данным

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

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

ГЛАВА 4

Контроллеры

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

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