УДК 004.622
Белянина Д.Н.
Димитровградский инженерно-технологический институт – филиал Национального исследовательского ядерного университета «МИФИ», Россия, г. Димитровград
АНАЛИЗ МЕТОДОВ ДОСТУПА К БАЗЕ ДАННЫХ В ASP.NET MVC
ANALYSIS OF METHODS OF DATABASE ACCESS IN ASP.NET MVC
Аннотация:в данной статье рассмотрены методы для доступа к базе данных в приложениях на веб-платформе ASP.NET. Приведен анализ используемых методов. Выявлены наиболее оптимальные методы при разработке веб-приложения
Abstract:this article describes methods to access database applications on the Web - a platform ASP.NET. The analysis methods used. Revealed the most optimal methods in the development of the web-application.
Существует большое множество методов для обновления базы данных при создании приложений на ASP.NET MVC4. Платформа ASP.NET MVC базируется на взаимодействии трех компонентов: контроллера, модели и представления. Контроллер принимает запросы, обрабатывает пользовательский ввод, взаимодействует с моделью и представлением и возвращает пользователю результат обработки запроса. Представление получает данные из контроллера и генерирует элементы пользовательского интерфейса для отображения информации. А модель представляет слой, описывающий логику организации данных в приложении.
Разработка любого бизнес-приложения, так или иначе, связана с обработкой определенного количества данных, выстраиванием связей между этими данными, а так же их удобным представлением. В данной статье проанализированы методы работы с межтабличным взаимодействием в ASP.NET MVC4:
— Linq to SQL;
— Linq to Entity;
— хранимая процедура.
Первым методом, выступающим в качестве метода доступа к данным является Linq to SQL - это API-интерфейс для работы с базами данных SQL Server.
Достоинство Linq to SQL заключается в том, что запросы обладают большой гибкостью и можно воспользоваться ассоциациями для выполнения более естественных запросов к базе данных.
Еще одним плюсом данного метода является возможность просматривать код выполнения запроса при запуске приложения в пределах отладчика.
DataContext — класс, устанавливающий соединение с базой данных. Он также предоставляет несколько служб, обеспечивающих отслеживание идентичности, отслеживание изменений и обработку этих изменений.
Для добавления новой записи в базу данных нужно создать новый объект и добавить запись в соответствующую коллекцию в DataContext. Если таблица использует столбец идентификаторов для первичного ключа – Linq to SQL автоматически обновит объект, как только он добавится в базу. Добавление объекта в соответствующую таблицу осуществляется с помощью метода InsertToSubmit. Данные будут существовать локально в DataContext, но не будут сохранены в базе данных пока не будет вызван метод SubmitChanges.
Кроме того можно удалять записи из базы данных. Для этого понадобится удалить сущностный объект, вызвав метод DeleteOnSubmit данного объекта. После этого необходимо вызвать метод SubmitChanges. При этом база данных в исходное состояние не восстанавливается. Удаление объекта содержит интересные аспектзависимые объекты автоматически не удаляются. Под зависимыми понимаются сущностные объекты, имеющие внешний ключ. Попытка удаления такого объекта приведет к нарушению ограничения внешнего ключа. Перед тем, как удалить сущностный объект, потребуется удалить все присоединенные к нему ассоциативные дочерние объекты. Это можно осуществить с помощью операции DeleteAllOnSubmit.
Редактирование записи осуществляется подобно добавлению и удалению, применяя метод UpdateOnSubmit.
При разработке простых приложений можно использовать Linq to SQL непосредственно в действиях контроллера. При построении более сложных приложений использование данного метода внутри класса контроллера затрудняет переключение технологий доступа к данным в будущем. К примеру, при переходе от Microsoft Linq to SQL к Microsoft Entity Framework необходимо будет переписывать каждый контроллер, который обращается к базе данных в приложении. Так же использование Linq to SQL внутри класса контроллера усложнит строительство модульных тестов приложения. Для того, что бы это избежать рекомендуется использовать шаблон репозитория - это класс, который содержит логику доступа к базе данных. Реализовать репозиторий можно с использованием различных технологий доступа к данным в будущем.
Подобно LINQ to SQL, LINQ to Entity позволяет работать с объектами, которые представляют информацию из базы данных, выполнять LINQ-запросы, изменять значения, добавлять и удалять объекты. И так же, как LINQ to SQL, первый шаг в направлении использования этих средств предусматривает генерацию классов, отображающих содержимое базы данных на объекты - то, что делается при создании сущностной модели данных (entity data model - EDM). Модель EDM состоит из набора объектов и свойств, которые используются для взаимодействия с данными.
Класс ObjectContext - это ключ для доступа к сущностной модели данных и эквивалент класса DataContext из LINQ to SQL. Класс ObjectContext отвечает за создание и управление соединением с базой данных, отслеживает изменения и управляет постоянством [1]. Именно класс ObjectContext соединяет с базой данных, когда создается новый экземпляр, и этот же класс отслеживает изменения, которые вносятся в объект, а также транслирует их в оператор SQL, сохраняющий изменения по вызову метода SaveChanges.
Подобно LINQ to SQL, запросы LINQ to Entity возвращают IQueryable
Для повышения производительности LINQ to Entity поддерживает скомпилированные запросы. Статический метод CompiledQuerу.Compile получает запрос и возвращает Func, принимающий ObjectContext и до 16 параметров запроса.
Часто бывает полезно увидеть оператор SQL, в который транслируется запрос LINQ to Entity. К сожалению, не существует удобного пути сделать это для всех операторов SQL, которые создает экземпляр ObjectContext. Однако просмотреть оператор SQL, который генерирует одиночный запрос LINQ to Entity, можно, приведя результат IQueryable
«Ленивая» загрузка объектов является поведением по умолчанию Linq to Entity. Связанные объекты загружаются из базы данных, только когда происходит обращение к ассоциированному свойству сущностного типа. То, что не нужно, никогда не загружается - это называется стратегией оперативной (just-in-time) загрузки, но это означает возможность получить неожиданно большое количество запросов SQL, генерируемых кодом.
Когда точно известно, какие данные понадобятся в коде, можно в качестве части запроса LINQ to Entity использовать метод Include для загрузки связанных сущностных объектов. Метод Include применяется к запросу указанием имени свойства ассоциации между запрашиваемым типом и типом, который требуется загрузить в виде строки.
Если необходим полный контроль, то лучше всего подойдет явная загрузка. Загружаемые связанные объекты указываются с использованием метода EntityCollection.Load.
Для использования явной загрузки ленивая загрузка должна быть отключена. В противном случае Entity Framework все равно загрузит связанные объекты автоматически.
Работая с таблицами и представлениями в ASP.NET напрямую, достаточно удобно считывать информацию из таблиц. Но часто бизнес-логика разрабатываемого приложения реализуется с помощью хранимых процедур.
Помимо этого, во многих приложениях пользователям вообще запрещается изменять данные кроме как через хранимые процедуры: для целей протоколирования, реализации дополнительных проверок, обеспечения правильности при каскадном обновлении данных. Хранимые процедуры обеспечивают модульность программирования, повышают производительность за счет более удобной работы с кэшем, а так же защищают от изменений в структуре базы данных.
Использование хранимых процедур несколько сложнее, чем использование представлений. Хранимая процедура должна быть явно импортирована в сущностную модель данных.
Для получения стандартного объекта DataReader на основе возвращаемых данных хранимой процедуры можно воспользоваться методом ExecuteReader объекта Command, или создавать DataSet через DataAdapter.
Обычной ситуацией для разработчика является передача хранимой процедуре значения параметров и принятие возвращаемых значений. Для этого используется коллекция Parameters объекта Command. При работе с SQL Server важны только имена объектов SqlParameter и порядок не важен, а при работе с источниками данных OLE DB важен порядок.
Если результатом обращения к хранимой процедуре является нетабличное значение, то можно получить, то, что вернет метод ExecuteNonQuery объекта кода.
Понятие не запросный (nonquery) означает оператор SQL, который не возвращает результирующий набор. Следовательно, операторы Select представляют собой запросы, а операторы Insert, Update и Delete - нет. Соответственно, метод ExecuteNonQuery() возвращает значение int, содержащее количество строк, на которые повлияли эти операторы, а не новое множество записей.
С помощью хранимых процедур можно сделать очень многое для повышения производительности системы. Но необходимо учитывать то, что, как и при использовании большинства других средств, нельзя рассчитывать на абсолютные гарантии. В действительности некоторые процессы, порождаемые с помощью хранимых процедур, способны существенно уменьшить производительность системы, если при проектировании хранимой процедуры не учитывались некоторые важные особенности функционирования хранимых процедур.
В данной работе осуществлен анализ часто используемых методов доступа к базам данных в ASP.NET MVC, каждый из которых имеет ряд достоинств и недостатков. В зависимости от разрабатываемого программного продукта разработчик выбирает тот или иной метод.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК:
1. Microsoft Developer Network. Режим доступа: msdn.microsoft.com (дата обращения: 20.02.2015).