C технология ado. Технологии ADO.NET

Технологии ADO .NET, . NET FrameWork, CORBA

Технология доступа к удаленным базам данных ADO .NET была разработана также для архитектуры клиент - сервер. Кроме двух уров­ней удаленных баз данных - клиентского и серверного - появля­ются дополнительные уровни - серверы бизнес-логики, реализу­ющие бизнес-логику приложений.

Технология ADO .NET устанавливает следующую схему рабо­ты клиента с сервером баз данных:

Установка соединения с сервером;

Получение необходимых данных;

Закрытие соединения;

Обработка данных;

Установка соединения для передачи измененных данных об­ратно на сервер.

Основу ADO .NET составляют два основных модуля:

Провайдер данных (Data Provider .NET FrameWork)

Резидентная реля­ционная база данных (DataSet).

Провайдер данных , как это следует из его название, отвечает за связь приложения с источником данных и за манипуляцию дан­ными. Провайдер данных включает в себя следующие объекты ма­нипулирования данными:

а) Connection используется для установления соединения с источ­ником данных, а также для управления транзакциями.

б) Command позволяет манипулировать данными источника, а также выполнять хранимые процедуры. При этом могут ис­пользоваться параметры для передачи данных в обоих направ­лениях.

в) DataAdapter служит связующим звеном между резидентной БД DataSet и источником данных и использует обычно объект Command для выполнения команд SQL как при заполнении DataSet данными, так и при обратной передаче измененных клиентом данных к источнику. Для выполнения этих функций в нем имеют­ся четыре метода: SelectCommand, InsertCommand, UpdateCommand и DeleteCommand.

г) DataReader обеспечивает получение данных от источника только для считывания. Если приложение клиента не модифицирует данные и не требуется произвольная выборка данных, а достаточно их однократного просмотра, то использование DataReader вместо DataSet позволит сохранить ресурсы компьютера, а также повы­сить быстродействие приложения.

Резидентная реляционная база данных представляет собой по­лученную клиентом реляционную БД, которая сохраняется в его резидентной оперативной памяти.

Далее клиент в автономном режиме производит обработку дан­ных и при необходимости модифицирует их, после чего снова устанавливается соединение с сервером и модифицированная информация из резидентной базы данных передается обратно.

Такая схема взаимодействия в некоторой степени походит на работу архитектуры файл -

сервер и часто применяется предприятиями при работе с удален­ными базами данных через глобальную сеть Интернет.

Для обеспечения доступа к объектам через глобальную сеть Ин­тернет в составе ADO .NET и был предусмотрен модуль.NET FrameWork обеспечивающий взаимодействие между различными форматами представления данных, в том числе HTML и XML.

Из указанных характеристик видно, что технология ADO .NET обеспечивает:

Возможность взаимодействия между данными различных фор­матов, в том числе HTML и XML;

Значительное снижение затрат при работе с удаленными ба­зами данных через глобальную сеть Интернет.

Когда архитекторы n-уровневой архитектуры оценивают какую-либо новую технологию, шаблон или стратегию, они решают, как эта новая часть головоломки будет сочетаться с архитектурой. Если есть платформа Entity Framework, интеграция не вызывает каких-либо сложностей. Она может быть интегрирована в n-уровневую архитектуру, а также в одноуровневую архитектуру.

19.03.2009 15:32

Entity Framework FAQ

Понимание моделирования сущностей, отображение таких моделей на реляционные базы данных, а также проектирование сущностных моделей данных (Entity Data Model, EDM) являются первыми шагами к пониманию Entity Framework. Я начну свою статью с ответов на вопросы об основах Entity Framework, в том числе о классе ObjectContext, а затем отвечу на вопросы о том, когда и где стоит использовать Entity Client с Entity SQL. Кроме того, я планирую объяснить разницу между EntityClient и службами Object Services, а также последствия использования запросов LINQ и Entity SQL вместе с этими службами.

16.02.2009 15:15

Обзор ADO.NET Entity Framework

В выпуске Visual Studio 2008 в ADO.NET представлена новая архитектура Entity Framework. Она позволяет разработчикам обращаться к данным, используя объектную модель вместо логической или реляционной модели данных. Entity Framework помогает абстрагировать логическую схему данных в концептуальную модель и обеспечивает несколько способов взаимодействия с концептуальной моделью через службы Object Services и нового поставщика данных, называющегося EntityClient. В статье этого месяца обсуждается, что такое архитектура Entity Framework, как она применяется в приложении и как с ее учетом разрабатывать и программировать.

13.02.2009 18:44

Разработка сущностной модели данных с помощью Entity Framework

Entity Framework — это новая технология, разработанная для ADO.NET. Она позволяет разработчикам визуализировать данные, используя логическую, а не физическую модель, благодаря чему обеспечивается определенная гибкость разработки. В июльском номере журнала за 2007 год в рубрике «Точки данных» мы давали подробный обзор технологии Entity Framework (она должна быть официально выпущена в первой половине 2008 года).

13.02.2009 18:33

Использование атрибутов для нормализации и валидации бизнес-сущностей

В корпоративном программировании при проектировании уровня доступа к данным часто встает вопрос работы с бизнес-объектами(бизнес-сущностями): это загрузки/изменения/сохранения и перемещения между уровнями. Существует два основных подхода для этого - использование собственных бизнес-сущностей или стандартных средств (ADO.NET предоставляет достаточно удобные способы для этого) - использование DataSet.

20.01.2007 03:54

ADO.NET: Обзор технологии

Многие программисты, работающие с базами данных на платформах Microsoft, могли оценить простоту и удобство технологии ADO - ActiveX Data Objects. Интутитивно-понятный интерфейс и логичный набор объектов вместе с простотой программирования заслуженно получили признание программистов. Несмотря на это, вместе с новой платформой.NET Microsoft представляет и новое поколение средств доступа к базам данных - ADO.NET.

27.12.2006 01:32

Операции над данными с иерархической структурой. Разработка распределенных приложений в.NET

Эта статья демонстрирует методику чтения и записи иерархических наборов строк в источнике данных. В примерах кода, приведенных в этой статье, для соединения с базой данных Microsoft SQL Server или Microsoft Desktop Engine (MSDE) используется управляемый провайдер SQL (SQL managed provider). Для соединения с другими OLEDB-совместимыми источниками данных следует применять управляемый провайдер ADO (ADO managed provider).

27.12.2006 01:26

Работа с автономными данными в ADO.NET

Технология ADO.NET, в отличие от своих предшественников ADO и OLE DB, была разработана специально для использования в web приложениях, где не бывает постоянных соединений с БД. Традиционная работа с данными в ADO.NET строится по такой схеме: создается соединение Connection, затем оно открывается методом Open, создается объект команда Command, инкапсулирующая SQL команду, она исполняется, а соединение затем закрывается. Такой подход обеспечивает поточный доступ к результатам запросов. Т.е. читая данные с помощью DataReader, вы не можете перепрыгнуть через несколько записей или вернуться к предыдущей. Поточный доступ имеет максимальную производительность.

В ADO.NET используется многоуровневая архитектура, которая обращается вокруг небольшого числа ключевых концепций, таких как объекты Connection, Command и DataSet. Однако архитектура ADO.NET серьезно отличается от классической архитекуры ADO.

Поставщики данных в ADO.NET

Поставщик данных (data provider) - это набор классов ADO.NET, которые позволяют получать доступ к определенной базе данных, выполнять команды SQL и извлекать данные. По сути, поставщик данных - это мост между вашим приложением и источником данных.

В первом приближении поставщик данных можно рассматривать как набор типов, определенных в данном пространстве имен, который предназначен для взаимодействия с конкретным источником данных. Однако независимо от используемого поставщика данных, каждый из них определяет набор классов, обеспечивающих основную функциональность. В таблице ниже приведены некоторые общие основные объекты, их базовые классы (определенные в пространстве имен System.Data.Common) и основные интерфейсы (определенные в пространстве имен System.Data), которые они реализуют:

Основные объекты поставщиков данных ADO.NET

Тип объекта	Базовый класс	Соответствующие интерфейсы	Назначение
Connection	DbConnection	IDbConnection	Позволяет подключаться к хранилищу данных и отключаться от него. Кроме того, объекты подключения обеспечивают доступ к соответствующим объектам транзакций
Command	DbCommand	IDbCommand	Представляет SQL-запрос или хранимую процедуру. Кроме того, объекты команд предоставляют доступ к объекту чтения данных конкретного поставщика данных
DataReader	DbDataReader	IDataReader, IDataRecord	Предоставляет доступ к данным только для чтения в прямом направлении с помощью курсора на стороне сервера
DataAdapter	DbDataAdapter	IDataAdapter, IDbDataAdapter	Пересылает наборы данных из хранилища данных к вызывающему процессу и обратно. Адаптеры данных содержат подключение и набор из четырех внутренних объектов команд для выборки, вставки, изменения и удаления информации в хранилище данных
Parameter	DbParameter	IDataParameter, IDbDataParameter	Представляет именованный параметр в параметризованном запросе
Transaction	DbTransaction	IDbTransaction	Инкапсулирует транзакцию в базе данных

Конкретные имена этих основных классов различаются у различных поставщиков (например, SqlConnection, OracleConnection, OdbcConnection и MySqlConnection), но все эти объекты порождены от одного и того же базового класса (в случае объектов подключения это DbConnection), который реализует идентичные интерфейсы (вроде IDbConnection). Поэтому если вы научитесь работать с одним поставщиком данных, то легко справитесь и с остальными.

В ADO.NET термин "объект подключения" на самом деле относится к конкретному типу, порожденному от DbConnection; объекта подключения "вообще" нет. То же можно сказать и об "объекте команды", "объекте адаптера данных" и т.д. По соглашению имена объектов в конкретном поставщике данных имеют префиксы соответствующей СУБД (например, SqlConnection, OracleConnection, SqlDataReader и т.д.).

Одной из ключевых идей, лежащих в основе модели поставщиков ADO.NET, является расширяемость. Другими словами, разработчики могут создавать собственные поставщики для патентованных источников данных. В действительности доступно множество подтверждающих это примеров, которые демонстрируют, как создавать настраиваемые поставщики ADO.NET, служащие оболочками для нереляционных хранилищ данных, таких как файловая система или служба каталогов. Некоторые независимые производители также продают собственные поставщики данных для.NET.

В рамках.NET Framework поставляется небольшой набор из четырех поставщиков:

SQL Server

Предоставляет оптимизированный доступ к базам данных SQL Server (версии 7.0 и выше).

OLE DB

Предоставляет доступ к любому источнику данных, который имеет драйвер OLE DB. Это включает базы данных SQL Server версий, предшествующих 7.0.

Oracle

Предоставляет оптимизированный доступ к базам данных Oracle (версии 8i и выше).

ODBC

Предоставляет доступ к любому источнику данных, имеющему драйвер ODBC.

В версии.NET 4 поставщик Oracle объявлен устаревшим. И хотя он по-прежнему работает, в Microsoft рекомендуют применять вместо него для доступа к базам данных Oracle поставщик от стороннего производителя, такой как ODP.NET (Oracle Data Provider для.NET) производства Oracle, который доступен на веб-сайте http://www.oracle.com . Этот поставщик обеспечивает расширенную поддержку для специализированных типов данных Oracle, вроде LOB, временных меток и данных XML, а также обладает несколькими дополнительными средствами.

На рисунке ниже показаны уровни модели поставщиков ADO.NET:

При выборе поставщика сначала пытайтесь найти встроенный поставщик.NET, который предназначен для имеющегося источника данных. Если таковой не найден, можно воспользоваться OLE DB при наличии драйвера OLE DB для источника данных.

Технология OLE DB существует уже много лет как часть ADO, поэтому для большинства источников данных предусмотрены драйверы OLE DB (включая SQL Server, Oracle, Access, MySQL и многие другие). В тех редких случаях, когда найти специализированный поставщик.NET или драйвер OLE DB не удается, можно обратиться к поставщику ODBC, который работает в сочетании с драйвером ODBC.

Стандартизация в ADO.NET

На первый взгляд может показаться, что ADO.NET предлагает фрагментированную модель, поскольку не включает обобщенного набора объектов, которые работали бы с множеством типов баз данных. В результате, когда вы переходите от одной реляционной СУБД к другой, приходится модифицировать код доступа к данным для использования другого набора классов.

Но даже несмотря на то, что разные поставщики данных.NET используют различные классы, все они некоторым образом стандартизированы. Точнее говоря, каждый поставщик основан на одном и том же наборе интерфейсов и базовых классов. Так, например, объект Connection реализует интерфейс IDbConnection, который определяет такие ключевые методы, как Open() и Close(). Подобная стандартизация гарантирует, что каждый класс Connection будет работать одинаковым образом и предоставит один и тот же набор ключевых свойств и методов.

"За кулисами" различные поставщики используют совершенно разные низкоуровневые вызовы и API-интерфейсы. Например, поставщик данных SQL Server применяет патентованный протокол TDS (Tabular Data Stream - поток табличных данных) для взаимодействия с сервером. Преимущества этой модели не сразу очевидны, но весьма существенны:

Поскольку каждый поставщик использует одни и те же интерфейсы и базовые классы, можно писать обобщенный код доступа к данным (с приложением небольших дополнительных усилий), работая с интерфейсами, а не классами поставщиков.

Поскольку каждый поставщик реализован отдельно, он может использовать соответствующую оптимизацию (это отличается от модели ADO, где каждый вызов базы данных должен проходить через общий уровень, прежде чем достигнет лежащего в основе драйвера базы данных). Кроме того, специализированные поставщики могут добавлять нестандартные средства, которых не имеют другие поставщики (например, возможность SQL Sever выполнять XML-запросы).

ADO.NET также имеет другой уровень стандартизации - DataSet . Класс DataSet - это контейнер данных общего назначения, которые извлекаются из одной или более таблиц источника данных. DataSet полностью обобщен; другими словами, специализированные поставщики не определяют собственных специализированных версий класса DataSet.

Независимо от того, какой поставщик данных применяется, можно извлекать данные и помещать их в полностью автономный DataSet одинаковым образом. Это облегчает отделение кода, извлекающего данные, от кода, обрабатывающего их. В случае смены лежащей в основе базы данных придется изменить только код, извлекающий данные, но если используется DataSet, а информация имеет одну и ту же структуру, модифицировать способ ее обработки не понадобится.

Фундаментальные классы ADO.NET

Классы ADO.NET группируются в несколько пространств имен. Каждый поставщик имеет свое собственное пространство имен, а обобщенные классы вроде DataSet находятся в пространстве имен System.Data. Ниже описаны наиболее важные пространства имен для базовой поддержки ADO.NET:

System.Data

Содержит ключевые классы контейнеров данных, которые моделируют столбцы, отношения, таблицы, наборы данных, строки, представления и ограничения. Дополнительно содержит ключевые интерфейсы, которые реализованы объектами данных, основанными на соединениях

System.Data.Common

Содержит базовые, наиболее абстрактные классы, которые реализуют некоторые из интерфейсов из System.Data и определяют ядро функциональности ADO.NET. Поставщики данных наследуются от этих классов (DbConnection, DbCommand и т.п.), создавая собственные специализированные версии

System.Data.OleDb

Содержит классы, используемые для подключения к поставщику OLE DB, включая OleDbCommand, OleDbConnection и OleDbDataAdapter. Эти классы поддерживают большинство поставщиков OLE DB, но не те, что требуют интерфейсов OLE DB версии 2.5

System.Data.SqlClient

Содержит классы, используемые для подключения к базе данных Microsoft SQL Server, в том числе SqlDbCommand, SqlDbConnection и SqlDbDataAdapter. Эти классы оптимизированы для использования интерфейса TDS к SQL Server

System.Data.OracleClient

Содержит классы, необходимые для подключения к базе данных Oracle (версии 8.1.7 и выше), в том числе OracleCommand, OracleConnection и OracleDataAdapter. Эти классы используют оптимизированный интерфейс OCI (Oracle Call Interface - Интерфейс вызовов Oracle)

System.Data.Odbc

Содержит классы, необходимые для подключения к большинству драйверов ODBC, такие как OdbcCommand, OdbcConnection, OdbcDataReader и OdbcDataAdapter. Драйверы ODBC поставляются для всех видов источников данных и конфигурируются через значок Data Sources (Источники данных) панели управления

System.Data.SqlTypes

Содержит структуры, соответствующие встроенным типам данных SQL Server. Эти классы не являются необходимыми, но предоставляют альтернативу применению стандартных типов данных.NET, требующих автоматического преобразования

Тем, кто пишет запросы в коде страницы посвящается...

Приветствую всех!

На хабре есть немного информации о том, что в следующей версии VisualStudio 2008 будет ADO.NET EntityFramework. (Открою секрет, эта версия уже появилась.) Эта разработка представляет собой универсальный фреймворк, который позволяет создавать даталогику вашего проекта в пару кликов мыши.
До сих пор, работая с даталогикой, я сталкивался с 2 видами проектов. Первые были созданы на небезызвестном фреймворке NHibernate , другие реализовывали даталогику программистами. Я уже 3 года занимаюсь написанием и разработкой различных систем и всё это время разрабатывал логику работы с данными исключительно ручками.
И вот, на днях, после того, как я поставил новую винду, я скачал VisualStudio WebDeveloper Express, и с радостью обнаружил в комплекте поставки ADO.NET EntityFramework. Через некоторое время зарегистрировал домен, создал простенький сайт, и начал тренировать свои силы в написании программ под этот фреймворк.

Для начала необходимо создать простой Web проект с базой данных. К базе данных тоже неплохо было бы подключится сразу через DataBase Explorer. Просто потом будет удобнее.

После этого, в проект надо добавить новый элемент «ADO.NET Entity Data Model».

Системе надо будет указать строку для соединения с базой, а так же указать, откуда возьмётся первая модель ADO.NET EF.

В своей БД я уже имею две очень простых таблицы Post и User, поэтому не мудрствуя лукаво, я заставил систему создать модель на основе моей БД. После всех этих, очень простых действий, я получил рабочую модель БД. Более того, изучив эту модель визуально, я не забыл заглянуть в код, и посмотреть, как же фрейворк описывает все мои классы?

1. namespace DataBaseCore
2. ///
3. /// There are no comments for DbModel in the schema.
4. ///
5. public partial class DbModel: global::System.Data.Objects.ObjectContext
6. ///
7. /// Initializes a new DbModel object using the connection string found in the "DbModel" section of the application configuration file.
8. ///
9. public DbModel() :
10. base ("name=DbModel" , "DbModel" )
11. this .OnContextCreated();
12. /* Урезал за ненадобностью */
16. public partial class Post: global::System.Data.Objects.DataClasses.EntityObject
17. ///
18. /// Create a new Post object.
19. ///
20. /// Initial value of Id.
21. public static Post CreatePost(int id)
22. Post post = new Post();
23. post.Id = id;
24. return post;

Намётанный глаз специалиста по работе с даталогикой показал наличие достаточно простого и изящного класса, который позволил работать как с постами в системе, так и с пользователями.

Ну, что же, код у нас уже есть, осталось только его начать использовать. И тут, нам открываются все прелести и возможности ASP.NET. Среди немалого количества источников данных на странице я увидел Entity Data Source, который с удовольствием предоставляет данные по запросу из нашего класса. Перетаскиваем его на форму, запускаем мастер настройки, и быстренько цепляем датасорс на нашу таблицу постов.

Несомненно, намного приятнее стало выглядеть описание датасорца в ASPX коде.

1. < asp:EntityDataSource ID ="dsPosts" runat ="server" ConnectionString ="name=DbModel"
2. DefaultContainerName ="DbModel" EntitySetName ="Post" >

* This source code was highlighted with Source Code Highlighter .

Можно сказать - блещет изяществом.

После появления на форме провайдера данных, нужен и потребитель. Не умничая, я добавил простенький код, который просто отображает все посты последовательно.

1. < asp:Repeater runat ="server" ID ="repPosts" DataSourceID ="dsPosts" >
2. < HeaderTemplate >
4. < ItemTemplate >
5. < div >
6. < h3 >
7. < asp:Label ID ="lblHeader" runat ="server" Text ="<%# Eval("Header") %>" >
9. < p >
10. < asp:Label ID ="lblText" runat ="server" Text ="<%# Helpers.TypographText(Eval("Text").ToString()) %>" >

* This source code was highlighted with Source Code Highlighter .

И вот тут заканчивается самая простая часть моего повествования. До сих пор, всё что было сделано, можно повторить при помощи мыши. Это было достаточно просто. Мы только что создали объектно-ориентированное представления БД, и используя это представление, начали выводить данные из базы на страницу. При этом, мы ни разу не написали ни одного запроса, не получали данные из базы напрямую, etc…

Но, что же выводить пользователю, если у нас нет ничего в БД? Нехорошо. Надо написать форму заполнения базы. Теперь мы бросим мышепрограммирование, и займёмся написанием кода.

Я сделал два самых базовых действия для работы с постами в системе - это добавление и удаление. Сделать редактирование по аналогии с этим кодом не составит труда ни для кого.

1. namespace DBW
2. public class Post
3. public Post()
4. public static void New(String PostText, String PostHeader, Int32 UserId)
5. p.Header = PostHeader;
6. p.Text = Helpers.TypographText(PostText);
7. p.PublishDate = DateTime .Now;
8. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
9. m.AddToPost(p);
10. m.SaveChanges();
11. public static void Delete(Int32 PostId)
12. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
13. DataBaseCore.Post p = new DataBaseCore.Post();
14. p = (from pst in m.Post where pst.Id == PostId select pst).First();
15. m.DeleteObject(p);
16. m.SaveChanges();

* This source code was highlighted with Source Code Highlighter .

Казалось бы, всё просто, и да, это так. Но есть пара нюансов.
Во-первых - это LINQ. Без него в ADO.NET никуда. Так что не стоит отлынивать и вообще забивать на SQL или LINQ, писать запросы всё равно придётся.
Во-вторых - этот код автоматически генерируется фреймворком, поэтому особого удобства в некоторых моментах ожидать не придётся, и всегда надо быть готовым изменить уже созданный студией код. Например, тут в строке 16 было бы удобнее использовать не объект типа пользователь, который мне пришлось выбирать из БД, а сразу передавать значение идентификатора пользователя. Так было бы удобнее для этого кода, но это не универсально. Поэтому код нуждается в доработке и переосмыслении. Возможно просто надо передавать не идентификатор пользователя, а объект типа пользователь.

Что дальше? Дальше я буду продолжать писать проект, углубляясь в дебри ADO.NET Entity Framework, и буду с удовольствием делиться своими изысканиями с вами, уважаемые хабраюзеры. Соответственно, будут новые статьи, с более серьёзными и глубокими данными.

UPD. Тема очень обширная. Здесь не раскрыто и процента возможностей, но продолжение будет 8-)