Asp.net mvc framework
Шрифт:
namespace="MyNamespace" assembly="MyNamespace">
<class name="Customer" table="Customers">
<id name="customerId">
<column name="customerId" not-null="true" />
<generator class="guid"/>
</id>
<property name="name" />
<property name="phone" />
<property name="address" />
</class>
</hibernate-mapping>
Здесь создается мэппинг класса Customer на таблицу Customers в базе данных, которая содержит ряд полей: customerId, name, phone, address. Для подключения к базе данных должен быть создан другой конфигурационный
<?xml version="1.0" encoding="utf-8"?>
<hibernate-configuration>
<session-factory xmlns="urn: nhibernate-configuration-2.2">
<property name=''connection.provider">
NHibernate.Connection.DriverConnectionProvider
</property>
<property name=''connection.driver_class">
NHibernate.Driver.SqlClientDriver
</property>
<property name="dialect">
NHibernate.Dialect.MsSql2005Dialect
</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, в зависимости от ваших пристрастий и предпочтений.