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 (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, в зависимости от ваших пристрастий и предпочтений.
Какой бы механизм вы не выбрали, основными принципами организации слоя доступа к данным должны оставаться слабая связанность с бизнеслогикой и возможность безболезненной замены этого слоя.
ГЛАВА 4
Контроллеры
В паттерне MVC контроллеры выполняют следующие последовательные функции:
□ контроллер реагирует на действия клиента, например: нажатие кнопки отправки формы на сервер, Ajax-запросы, которые генерирует браузер, и др.;
□ контроллер оперирует с моделью, изменяя ее состояние;
□ контроллер выбирает представление, которому передает модель данных, тем самым представление формируется контроллером и отображается пользователю либо передается в виде набора данных клиентскому программному обеспечению.
Назначение контроллеров
Обзор контроллеров в ASP.NET MVC
Для разработчика ASP.NET MVC-контроллер представляет собой класс, унаследованный от базового класса Controller (который в свою очередь унаследован от класса ControllerBase, реализующего интерфейс IController). Каждый файл контроллера MVC Framework должен подчиняться следующим требованиям:
□ располагаться в папке Controllers корня проекта;
□ иметь суффикс Controller, например HomeController.cs, AccountController.cs;
