Доступ к данным

На сегодняшний день Microsoft предлагает для платформы.Net по крайней мере три технологии доступа к данным, рассмотрим каждую из них.

ADO.Net – это набор классов, предоставляющих службы доступа к данным программисту. ADO.NET имеет богатый набор компонентов для создания распределенных приложений, совместно использующих данные [3]. Данная технология очень популярна, т. к. она надежна и используется уже много лет. Кроме этого, для ADO.Net существует большое количество провайдеров данных, поэтому в качестве СУБД можно использовать различные продукты – MS SQL Server, Oracle Database, MySQL, FirebirdSQL и т. д. ADO.Net можно сопоставить паттерн Table Data Gateway (шлюз к данным таблицы), описанный М. Фаулером [25]. Посмотрим, как работает ADO.Net.

Доступ к объектам базы осуществляется путем передачи на сервер кода SQL, команд запуска хранимых процедур или функций. При использовании этой технологии для каждой операции выборки, вставки, удаления или изменения строк в таблицах, как правило, пишется своя хранимая процедура, которую в нужный момент запускают с помощью классов ADO.Net. Это упрощает обслуживание системы в тех случаях, когда доступен лишь сервер БД и нет возможности изменить код на клиенте. К сожалению, при этом можно изменить только логику хранимой процедуры, а не сигнатуру (количество и тип параметров), поскольку в последнем случае процедура не будет совместима с вызывающим её кодом. Программисту требуется написать не только логику работы с базой в виде триггеров, функций и процедур, но и методы для работы с этими объектами базы в коде приложения. Кроме этого, необходимо реализовать некоторое количество классов (т. н. сущностей), с помощью которых будет выполняться дальнейшая логика работы с данными - отображение значений в таблицах пользовательского интерфейса, сериализация в xml на веб-сервисе или запись в файл. Для того, чтобы упростить код, который выполняет обмен данными с базой, можно и нужно обобщать его – писать интерфейсы, абстрактные классы, различные универсальные методы. Однако чем абстрактнее такая система классов, тем больше времени нужно на её проектирование и разработку, что в общем делает дороже весь проект. Будут ли оправданными эти траты? Безусловно, если на разработку проекта выделены большие средства, а также сроки выполнения велики и особенно в тех случаях, когда во главу угла ставится скорость работы. Технология ADO.Net позволяет гибко выстроить работу с базой, т.к. SQL-запросы пишутся вручную, и их можно очень хорошо оптимизировать, тем самым повысив скорость выполнения запросов и уменьшив сетевой трафик.

Кроме описанных выше преимуществ, ADO.Net имеет и существенные недостатки. Самый главный – необходимость написания большого количества SQL-кода вручную. Кроме того, возникает необходимость ручного разбора результатов запросов, а также самостоятельного создания классов бизнес-сущностей. Все это увеличивает время разработки.

LINQ to SQL. В этой технологии модель данных реляционной базы данных сопоставляется объектной модели, выраженной в языке программирования разработчика. При запуске приложения LINQ to SQL преобразует запросы LINQ из объектной модели в SQL и отправляет их в базу данных для выполнения. Когда база данных возвращает результаты, LINQ to SQL преобразует их обратно в объекты, с которыми можно работать на собственном языке программирования [4]. LINQ to SQL можно сопоставить паттерн Active Record (активная запись), описанный М. Фаулером [26]. Для генерации набора классов, соответствующих сущностям БД, обычно используется встроенный в Visual Studio инструмент – ORM-дизайнер. С его помощью можно автоматически создать классы языка программирования (C# или Visual Basic.Net), которые можно использовать в дальнейшем для любых нужд. Все операции вставки, обновления, удаления записей в таблицах БД можно делать при помощи специального класса LINQ to SQL – контекста. Фактически, работа с базой данных превращается просто в работу с набором классов, где запросы формируются на языке C# (VB.Net) с использованием лямбда-выражений LINQ to SQL. Плюсы такого подхода – упрощается отладка, нет необходимости писать хранимые процедуры, все данные из базы доступны в виде сущностей и коллекций сущностей, которые могут быть сразу привязаны к компонентам пользовательского интерфейса, либо сериализованы для дальнейшей передачи через веб-сервис.

Вместе с этим, применение LINQ to SQL накладывает на систему некоторые ограничения – технология не поддерживает серверы БД, отличные от MS SQL Server, а также зачастую формирует не совсем оптимальные SQL-запросы.

LINQ to Entities — позволяет разработчикам создавать приложения для доступа к данным, работающие с концептуальной моделью приложения, а не напрямую с реляционной схемой хранения. Цель состоит в уменьшении объема кода и снижении затрат на сопровождение приложений, ориентированных на обработку данных. [5]. Технология схожа с LINQ to SQL, но имеет некоторые отличия. LINQ to Entities, в отличие от LINQ to SQL, поддерживает работу с СУБД, отличными от MS SQL Server [6] [7], в частности, с Oracle Database [8]. Технологии можно сопоставить паттерн Domain Model (модель области определения), описанный М. Фаулером [27]. Кроме этого, LINQ to Entities позволяет использовать модель сущностей, которая значительно отличается от соответствующей модели данных [6] [7], в то время как LINQ to SQL создает жесткую привязку генерируемых классов к таблицам базы данных: одна таблица – один класс. Фактически, структура модели LINQ to Entities не привязана к источнику данных – необходимо лишь проставить соответствия свойства генерируемых классов с реальными столбцами таблиц или представлений БД. Вместе с тем, LINQ to SQL позволяет использовать собственные классы сущностей, наследоваться от интерфейсов или базового класса сущностей. В LINQ to Entities такой возможности нет.

Можно сделать вывод, что использовать LINQ to Entities разумно в больших проектах со сложной структурой данных, а также в случаях, когда необходима поддержка сторонних СУБД (не MS SQL Server).

Как показывает опыт автора, времени на проектирование и написание кода, как правило, всегда мало – и архитекторы, и разработчики ищут пути наименьшего сопротивления. В большинстве ситуаций технология ADO.Net себя не оправдывала, и её применение в некоторых проектах было обусловлено совместимостью с ранее написанным кодом. Однако в силу достаточного большого возраста технологии, у разработчиков накоплено значительное количество наработок – фреймворков, оберток, вспомогательных классов, применение которых несколько сглаживает недостатки ADO.Net. В новых же проектах всегда использовались технологии LINQ to SQL или LINQ to Entities, в которых возможность автоматического создания классов из сущностей БД значительно уменьшило время разработки, сократило размер написанного кода, а также сделала его более понятным. Хорошо зарекомендовал себя комбинированный способ – на ASP.Net сайте системы, где размещается приложение Silverlight, использовать LINQ to Entities, т. к. часто необходимо создавать сложные сущности на основе уже имеющихся, и очень удобно редактировать модель прямо в ORM-дизайнере. Напротив, для служб, которые выполняют в фоне анализ данных и работают напрямую с БД, проще обойтись технологией LINQ to SQL, сущности которой жестко привязаны к сущностям базы.

Дата добавления: 2015-07-14