Ado net примеры. Технологии ADO.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-)

Обзор ADO.NET

ADO.NET - нечто большее, чем надстройка над каким-нибудь существующим API-интерфейсом. Сходство с ADO минимально; классы и методы доступа к данным довольно существенно отличаются.

ADO (ActiveX Data Objects) - это библиотека компонентов СОМ, получившая в последние несколько лет множество воплощений. ADO состоит, прежде всего, из объектов Connection, Command, Recordset и Field. С помощью ADO открывается соединение с базой данных, после чего некоторые данные извлекаются и помещаются в набор записей, состоящих из полей; эти данные затем претерпевают манипуляции и обновления на сервере, после чего соединение закрывается. Кроме того, ADO предлагает так называемый отключенный набор записей (disconnected record set) , который используется, когда соединение с базой нежелательно удерживать открытым в течение длительного времени.

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

Более того, если вы используете SQL Server, существует замечательный набор управляемых классов, которые настроены на обеспечение максимальной производительности базы данных. Одного этого достаточно для перехода на ADO.NET.

ADO.NET поставляется с тремя пространствами имен клиента базы данных: одно для SQL Server , другое для источников данных Open Database Connectivity (ODBC) и третье для любой базы данных, доступной через OLE DB . Если выбрана база данных, отличная от SQL Server, отдавайте предпочтение OLE DB, если только не окажется, что нет другого выбора кроме ODBC. Если в качестве базы данных используется Oracle, можете посетить сайт Oracle .NET Developer и получить там их поставщика.NET - ODP.NET на странице www.oracle.com/technology/tech/windows/odpnet/index.html .

С точки зрения программиста, тело ADO.NET составляет базовая сборка с именем System.Data.dll . В этом двоичном файле находится значительное количество пространств имен, многие из которых представляют типы конкретного поставщика данных ADO.NET:

Большинство шаблонов проектов Visual Studio 2010 автоматически ссылаются на эту ключевую библиотеку доступа к данным. Однако для импортирования нужных пространств имен необходимо изменить кодовые файлы, например:

Using System; using System.Data; using System.Data.SqlClient; ...

Учтите также, что кроме System.Data.dll, существуют и другие ориентированные на ADO.NET сборки (например, System.Data.OracleClient.dll и System.Data.Entity.dll ), которые необходимо вручную указывать в текущем проекте с помощью диалогового окна Add Reference (Добавление ссылки).

Три стороны ADO.NET

Библиотеки ADO.NET можно применять тремя концептуально различными способами: в подключенном режиме, в автономном режиме и с помощью технологии Entity Framework. При использовании подключенного уровня (connected layer) , кодовая база явно подключается к соответствующему хранилищу данных и отключается от него. При таком способе использования ADO.NET обычно происходит взаимодействие с хранилищем данных с помощью объектов подключения, объектов команд и объектов чтения данных.

Автономный уровень (disconnected layer) , позволяет работать с набором объектов DataTable (содержащихся в DataSet), который представляет на стороне клиента копию внешних данных. При получении DataSet с помощью соответствующего объекта адаптера данных подключение открывается и закрывается автоматически. Понятно, что этот подход помогает быстро освобождать подключения для других вызовов и повышает масштабируемость систем.

Когда архитекторы 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, вы не можете перепрыгнуть через несколько записей или вернуться к предыдущей. Поточный доступ имеет максимальную производительность.