69066

Архітектура ADO.NET

Лекция

Информатика, кибернетика и программирование

На початку 1990 років існувало декілька постачальників баз даних, кожен з яких мав власний інтерфейс. Якщо застосуванню було необхідно підключатися до кількох джерел даних, для взаємодії з кожною з баз даних був необхідний нестандартний код.

Украинкский

2014-09-29

351 KB

1 чел.

Лекція №10

Архітектура ADO.NET

Слайд №3. Технології Microsoft для роботи з БД:

  •  ODBC API (Open Database Connectivity)  з використанням драйверів баз даних (опис джерел даних);
  •  RDO (Remote Data Objects)  об'єктна надбудова над ODBC;
  •  DAO (Data Access Objects)  об'єктна модель для доступу до MS Jet та ISAM/VSAM баз даних;
  •  OLE DB  відкритий низькорівневий інтерфейс, який визначає стандарт доступу до будь-яких даних, як до реляційних, так і до всіх інших (основа ініціативи UDA);
  •  ADO (ActiveX Data Objects)  високорівневий інтерфейс до OLE DB;
  •  ADO.NET з використанням керованих провайдерів БД.

ODBC (DataBase Connectivity) — це відкритий інтерфейс доступу до баз даних, розроблений консорціумом X/Open.

На початку 1990 років існувало декілька постачальників баз даних, кожен з яких мав власний інтерфейс. Якщо застосуванню було необхідно підключатися до кількох джерел даних, для взаємодії з кожною з баз даних був необхідний нестандартний код. Для вирішення цієї проблеми Microsoft та ряд інших компаній створили стандартний інтерфейс для отримання і відправки даних джерелам даних різних типів. Цей інтерфейс отримав назву open database connectivity (відкритий зв'язок з базами даних).

За допомогою ODBC програмісти могли розробляти застосунки для використання одного інтерфейсу доступу до даних, не турбуючись про тонкощі взаємодії з кількома джерелами.

MFC удосконалила ODBC для розробників застосувань. Дійсний інтерфейс ODBC є звичайним функціональним API. Замість створення простої оболонки функціонального API, розробники MFC створили набір абстрактних класів, що представляють логічні сутності в базі даних.

При застосуванні ODBC потрібно пам'ятати, що ця технологія доступу до даних не розрахована на роботу з великою кількістю клієнтів. Якщо необхідно забезпечити одночасну роботу з БД багатьох активних клієнтів, то слід використовувати SQL API або спеціальний інтерфейс для взаємодії з конкретною БД.

DAO (Data Access Objects) – це перший об'єктно-орієнтований інтерфейс, який реалізує движок баз даних Microsoft Jet Engine (використовується у Microsoft Access) та дозволяє розробникам Visual Basic встановлювати пряме з’єднання з таблицями Access (а також інших баз даних) через ODBC. DAO найкраще підходить для одно-системних застосувань або для невеликих, локальних розгортань.

DAO– об'єкт що надає абстрактний інтерфейс до деяких видів баз даних чи механізмів персистентності реалізуючи певні операції без розкриття деталей бази даних. Він надає відображення від програмних викликів до рівня персистентності. Така ізоляція розділює запити до даних в термінах предметної області та їх реалізацію засобами СКБД.

Цей паттерн проектування застосовний до більшості мов програмування, видів програмного забезпечення з потребою персистентності та більшості типів баз даних, але традиційно асоціюється з застосунками Java EE та реляційними БД доступ до яких здійснюють через JDBC API що пов'язано з походженням паттерна із збірки найкращих практик Sun Microsystems.[1] ("Core J2EE Patterns") для цієї платформи.

RDO (Remote Data Objects) – це поєднання об'єктно-орієнтованого інтерфейсу доступу до даних у ODBC з притаманною DAO простою використання, що забезпечує інтерфейс з практично всією низькорівневою потужністю і гнучкістю ODBC. Однак RDO має певні обмеження, оскільки не дуже добре надає доступ до баз даних Jet та ISAM, а також може отримати доступ до реляційних баз даних тільки за допомогою існуючих ODBC-драйверів. Тим не менш, RDO широко застосовувався великими розробниками реляційних баз даних SQL Server, Oracle та інших. RDO надає об'єкти, властивості та методи, необхідні для переходу до більш складних аспектів збережених процедур і складних результуючих.

RDOтехнологія доступу до баз даних компанії Microsoft. Являє собою набір COM-об'єктів, що інкапсулюють ODBC API, а також клієнтську курсорну бібліотеку.

Технологія RDO з'явилася у 1995 році одночасно з виходом продукту Visual Basic 4.0.

RDO позиціонувалася як технологія більш проста ніж пряме використання викликів ODBC і у той же час більш ефективна ніж технологія DAO. RDO була орієнтована на обробку даних на стороні сервера БД (такого як MS SQL Server, Oracle тощо) на відміну від DAO орієнтованої в основному на обробку даних на стороні клієнта.

У 1997 у складі продукту Microsoft Office 97 вийшла версія RDO 2.0. Вона також відома під назвою "ODBC Direct". Використовувалася в Microsoft Access та інших продуктах.

Вже з 1996 року Microsoft стала просувати нову технологію ADO, ніяк не пов'язану з ODBC, як перспективний спосіб доступу до даних, що сильно підірвало позиції RDO. В даний час (2005 рік) технологія практично не використовується.

OLE DB (Object Linking and Embedding, Database)  набір інтерфейсів, заснованих на COM, які дозволяють застосуванням звертатися до даних, збережених у різних джерелах інформації або сховищах даних за допомогою уніфікованого доступу.

OLE DB – це API, розроблене Microsoft для доступу до різних типів даних, які зберігаються в єдиній формі. Програма являє собою набір інтерфейсів реалізованих за допомогою Component Object Model (COM), в даному випадку це пов'язано з OLE. Вона була розроблена в якості подальшого розвитку і повинна була прийти на заміну в якості наступника ODBC, розширюючи набір функцій для підтримки більш широкого кола нереляційних джерел даних, таких як об'єктно-орієнтовані бази даних або електронні таблиці, і для яких не обов'язково використовувати SQL.

ADO (ActiveX Data Objects)  інтерфейс програмування застосувань для доступу до даних, розроблений компанією Microsoft (MS Access, MS SQL Server) і заснований на технології компонентів ActiveX. ADO дозволяє представляти дані з різноманітних джерел (реляційних баз даних, текстових файлів тощо) в об'єктно-орієнтованому вигляді.

ADO є наступником DAO/RDO. Функціонально ADO 2.0, найбільш схожий на RDO.

ADO.NET (ActiveX Data Objects .NET) — це набір бібліотек, що поставляється з Microsoft .NET Framework і призначений для взаємодії з різними сховищами даних з .NET-застосунків. Бібліотеки ADO.NET включають класи для приєднання до джерела даних, виконання запитів і обробки їхніх результатів. Крім того, ADO.NET можна використовувати в якості надійного, ієрархічно організованого, відокремленого кешу даних для автономної роботи з даними.

Слайд №10. ADO.NET використовує багаторівневу архітектуру, яка обертається навколо невеликої кількості ключових концепцій, таких як об'єкти Connection, Command та DataSet. Однак архітектура ADO.NET серйозно відрізняється від класичного ADO.

Одна з ключових відмінностей між ADO та ADO.NET полягає у тому, як вони справляються з різними джерелами даних. В ADO програмісти завжди використовують узагальнений набір об'єктів, незалежно від джерел даних, що лежать в їх основі. Наприклад, якщо необхідно отримати запис з бази даних Oracle, використовується той же клас Connection, що застосовується для виконання тієї ж задачі в SQL Server. Це не стосується ADO.NET, який використовує модель провайдерів даних.

Провайдери даних ADO.NET

Провайдери даних (data provider) – це набір класів ADO.NET, які дозволяють отримувати доступ до визначеної БД, виконувати команди SQL і витягувати дані. По суті, провайдер даних – це міст між застосуванням і джерелом даних.

Класи, з яких складається провайдер даних:

Connection –використовується для встановлення з'єднання з джерелом даних.

Command –використовується для виконання команд SQL і збережених процедур.

DataReader – надає швидкий випереджаючий доступ тільки для читання до даних, отриманих за запитом.

DataAdapter – виконує два завдання – наповнення DataSet (автономної колекції таблиць і відносин) інформацією, отриманої з джерела даних, та може використовуватися для застосування змін даних до джерела даних у відповідності з модифікаціями, які були виконані у DataSet.

ADO.NET не містить об'єктів узагальнених провайдерів даних. Замість цього він включає набір спеціалізованих провайдерів для різних джерел даних. Кожен провайдер даних має специфічну реалізацію класів Connection, Command, DataReader та DataAdapter, оптимізованих для конкретних реляційних СКБД. Наприклад, якщо необхідно створити підключення до бази даних SQL Server, використовується клас з'єднання за іменем SqlConnection.

На замітку! У цій книзі використовуються узагальнені імена для специфічних для провайдера об'єктів. Іншими словами, замість обговорення об'єктів SqlConnection і OracleConnection будемо говорити про всі об'єкти підключення. Слід мати на увазі, що це не узагальнений об'єкт Connection, а просто скорочене посилання на специфічний для провайдера об'єкт підключення, який працює стандартним чином.

Слайд №11. Одна з ключових ідей, що лежать в основі моделі провайдера ADO.NET, є її розширюваність. Іншими словами, розробники можуть створювати свої власні провайдери для відповідних типів даних. Фактично доступно безліч концептуальних прикладів, які показують, як можна створювати власні провайдери ADO.NET, які слугують оболонками для нереляційних сховищ даних, таких як файлова система чи служба каталогів (Active Directory). Деякі незалежні постачальники також продають власні провайдери даних для .NET.

.NET Framework пов'язаний з невеликим набором, що складається з чотирьох провайдерів:

• Провайдер SQL Server – надає оптимізований доступ до баз даних SQL Server (версії 7.0 і вище).

• Провайдер OLE DB – надає доступ до будь-якого джерела даних, який має драйвер OLE DB. Включає бази даних SQL Server версій, що передують 7.0.

• Провайдер Oracle – надає оптимізований доступ до баз даних Oracle (версій 8 і вище).

• Провайдер ODBC – надає доступ до будь-якого джерела даних, що має драйвер ODBC.

Слайд №13. На рис. 7.1 показані рівні моделі провайдерів ADO.NET.

 

Рис. 7.1. Архітектура ADO.NET

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

Порада. Microsoft включає провайдера OLE DB в ADO.NET, тому можна використовувати наявні у драйвери OLE DB. Однак якщо вдається знайти спеціалізованого провайдера для цього джерела даних, має сенс використовувати саме його. Наприклад, можна підключитися до бази даних SQL Server, використовуючи або спеціалізований провайдер SQL Server, або провайдер OLE DB, однак провайдер SQL Server завжди кращий.

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

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

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

"За кулісами" різні провайдери використовують абсолютно різні низькорівневі виклики та програмні інтерфейси. Наприклад, провайдер даних SQL Server застосовує патентований протокол TDS (Tabular Data Stream – потік табличних даних) для взаємодії з сервером. Переваги цієї моделі не цілком очевидні, але дуже істотні:

• Оскільки кожен провайдер використовує одні й ті ж інтерфейси та базові класи, можна написати узагальнений код доступу до даних (з невеликими додатковими зусиллями), кодуючи для інтерфейсів, а не класів провайдерів.

• Оскільки кожен провайдер реалізований окремо, він може використовувати відповідну оптимізацію (це відрізняється від моделі ADO, де кожен виклик бази даних повинен фільтруватися через загальний рівень, перш ніж досягне драйверу бази даних). На додаток, спеціалізовані провайдери можуть додавати нестандартні засоби, яких не мають інші провайдери (наприклад, можливість SQL Sever виконувати XML-запити).

ADO.NET також має інший рівень стандартизації – DataSet. DataSet – це контейнер даних загального призначення, які отримуються з однієї або більше таблиць джерела даних. DataSet повністю узагальнено; іншими словами, спеціалізовані провайдери не визначають власних спеціалізованих версій класу DataSet. Незалежно від того, який провайдер даних використовується, можна отримувати дані і розміщати їх у повністю автономному DataSet однаковим чином. Це полегшує відділення коду, що витягає дані, від коду, що їх обробляє. Якщо змінити базу даних, доведеться поміняти тільки код, який видобуває дані, але якщо застосувати DataSet і не змінювати при цьому структуру інформації, то не доведеться модифікувати спосіб її обробки.

Порада. У наступному розділі DataSet описується більш детально. Тут же ми знайомимо вас тільки про основами застосування ADO.NET для здійснення прямого, орієнтованого на з'єднання, доступу до даних.

Слайд №14. Способи роботи з базами даними:

1. Приєднаний або з підтримкою з'єднання (Connected): Forward-only, read-only

  •  Програма робить запит, потім читає результати і обробляє їх
  •  Використовується курсор "Firehose" (брандспойт)
  •  Використовується об'єкт DataReader

2. Від’єднаний або з розривом з'єднання (Disconnected)

  •  Програма робить запит, потім читає і зберігає результати для обробки, від'єднується від БД
  •  Виконується робота з даними (додавання, зміна, видалення)
  •  Мінімізується час з'єднання з базою даних
  •  Використовується об'єкт DataSet

Рис. Обєктна модель ADO.NET

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

ADO.NET має два типи об'єктів: засновані на з'єднанні і засновані на вмісті.

• Об'єкти, засновані на з'єднанні. Існують об'єкти провайдера даних, такі як Connection, Command та DataReader. Вони виконують SQL-оператори, підключаються до баз даних або заповнюють DataSet. Об'єкти, засновані на з'єднанні, специфічні для типу джерела даних.

• Об'єкти, засновані на вмісті. Ці об'єкти у дійсності лише "упаковують" дані. Вони включають DataSet, DataColumn, DataRow, DataRelation і ряд інших. Вони повністю незалежні від типу джерела даних і знаходяться в просторі імен System.Data.

Розглянемо перший рівень ADO.NET – об'єкти, засновані на з'єднанні, включаючи Connection, Command та DataReader. Ми поки не будемо говорити про високорівневі класі DataAdapter, оскільки DataAdapter призначений для використання з DataSet і обговорюється пізніше. По суті справи, DataAdapter – це група взаємозв'язаних об'єктів Command; ці об'єкти допомагають синхронізувати DataSet з джерелом даних.

Примітка. Провайдер ADO.NET – це просто набір класів ADO.NET (з реалізацією Connection, Command, DataAdapter та DataReader), які поставляються у збірці – бібліотеці класів. Звичайно всі ці класи провайдера мають один і той же префікс. Наприклад, префікс Oracle використовується для провайдера даних ADO.NET бази Oracle, який передбачає реалізацію об'єкта Connection за іменем OracleConnection.

Класи ADO.NET групуються у кілька просторів імен. Кожен провайдер має свій власний простір імен, а узагальнені класи накшталдт DataSet знаходяться у просторі імен System.Data. У табл. 7.1 описуються простори імен.

Концепція доступу до даних в ADO .NET базується  на використанні двох компонентів:

  1.  НАБОРУ ДАНИХ (представляється об'єктом класу DataSet) збоку клієнта. Це локальне тимчасове сховище даних;
  2.  ПРОВАЙДЕРА ДАНИХ (представляється об'єктом класу .Net data provider). Це посередник, що забезпечує взаємодію програми і бази даних збоку бази даних (в розподілених застосуваннях – збоку сервера).

Клас Connection

Клас Connection дозволяє встановлювати з'єднання з джерелами даних, з якими потрібно взаємодіяти. Перед тим, як зробити щось ще (зокрема отримання, видалення, вставку або оновлення даних), слід встановити з'єднання.

Ключові властивості і методи Connection специфіковані інтерфейсом IDbConnection, який реалізують всі класи Connection.

Рядки з'єднань. При створенні об'єкту Connection необхідно застосувати рядок з'єднання. Рядок з'єднання – це серія пар "ім'я-значення", розділених крапкою з комою (;). Порядок цих налаштувань не важливий, як і регістр. Всі разом вони специфікують базову інформацію, необхідну для встановлення з'єднання.

Таблиця 7.1. Простори імен ADO.NET

Простір імен

Опис

System.Data

Містить ключові контейнерні класи даних, що моделюють стовпці, відношення, таблиці, набори даних, рядки, представлення та обмеження. Додатково містить ключові інтерфейси, що реалізуються об'єктами динних, заснованими на з'єднаннях.

System.Data.Common

Містить базові, найбільш абстрактні класи, що реалізують деякі з інтерфейсів з System.Data, і визначають ядро функціональності ADO.NET. Провайдери даних успадковуються від цих класів, створюючи свої власні спеціалізовані версії.

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. Ці класи використовують оптимізований інтерфейс Oracle Call Interface (Інтерфейс виклику Oracle) або OCI.

System.Data.Odbc

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

System.Data.SqlTypes

Містить структури, що відповідають рідним типам даних SQL Server. Ці класи не є необхідними, але представляють альтернативу застосуванню стандартних типів даних .NET, що вимагають автоматичного перетворення.

Хоча рядки з'єднань варіюються в залежності від реляційної СКБД та використовуваного провайдера даних, майже завжди наявні декілька фрагментів інформації:

• Сервер, на якому знаходиться БД. У прикладах сервер БД завжди розташований на тому ж комп'ютері, що і застосування ASP.NET, тому замість імені комп'ютера використовується псевдонім localhost.

• БД, яку слід використовувати. У більшості прикладів використовується БД Northwind, яка інсталюється за промовчанням з більшістю редакцій SQL Server.

• Як база аутентифікує клієнта/користувача. Провайдери даних Oracle та SQL Server надають можливість вибору – застосувати певний "мандат" (з ім'ям і паролем) або підключитися як поточний користувач системи. Останній варіант зазвичай кращий, оскільки в цьому випадку не потрібно поміщати інформацію про пароль у код або конфігураційні файли.

Наприклад, нижче представлений рядок з'єднання, використовуваного для підключення до бази даних Northwind на поточному комп'ютері, з використанням інтегрованої безпеки (тобто з підключенням до бази поточного користувача Windows):

string connectionString =

"Data Source=localhost;Initial Catalog=Northwind;" +

"Integrated Security=SSPI";

Якщо інтегрована безпека не підтримується, при підключенні повинні бути вказані коректні ім'я та пароль користувача. В знову встановленій базі даних SQL Server зазвичай присутній обліковий запис системного адміністратора sa (system administrator). Рядок з'єднання, що використовує цей обліковий запис:

string connectionString =

"Data Source=localhost;Initial Catalog=Northwind;" +

"user id=sa; password=opensesame";

При використанні провайдера OLE DB рядок з'єднання буде схожим на попередній, але зявляться додаткові настройки, що ідентифікують драйвер OLE DB. Наприклад, можна застосовувати наступний рядок з'єднання для підключення до бази даних Oracle через драйвер MSDAORA OLE DB:

string connectionString = "Data Source=localhost;Initial Catalog=Sales;" +

"user id=sa;password=;Provider=MSDAORA";

А ось приклад підключення до файлу бази даних Access:

string connectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" +

@"Data Source=C:\DataSources\Northwind.mdb";

Порада. При використанні бази даних, відмінної від SQL Server, слід переглянути документацію провайдера даних (або інструкцію до бібліотеки класів .NET Framework), щоб дізнатися, які значеннях рядка з'єднання підтримуються. Наприклад, більшість БД підтримують налаштування тайм-ауту з'єднання, що встановлює час очікування з'єднання у секундах до того, як має бути згенеровано виключення (для SQL Server за промовчанням прийнято 15 секунд).

При створенні об'єкта Connection можна передати рядок з'єднання в якості параметра конструктора. Або можна вручну встановити значення властивості ConnectionString, якщо це робиться до спроби відкрити з'єднання.

Немає причин жорстко кодувати рядок з'єднання. Розділ <connectionString> файлу web.config – це підходяще місце для збереження рядка з'єднання, наприклад:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

<connectionStrings>

     <add name="Northwind" connectionString=

     "Data Source=localhost;Initial Catalog=Northwind;Integrated Security=SSPI"/>

</connectionStrings>

...

</configuration>

Потім можна витягти цей рядок з'єднання за іменем з колекції WebConfigurationManager.ConnectionStrings наступним чином:

Рядок connectioriStrincj =
WebConfigurationManager.ConnectionStrings ["Борей"] ConnectionString.

У наведених нижче прикладах передбачається, що ви додали цей рядок з'єднання в свій файл web.config.

Тестування з'єднання. Одного разу вибравши рядок з'єднання, керувати підключенням дуже легко – слід просто використовувати методи Open() та Close(). Наступний код в обробнику події Page.Load можна використовувати для перевірки з'єднання і виведення його стану в текст мітки (як показано на рис 7.2.):

// Створити обєкт Connection.

string connectionString =

WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

SqlConnection con = new SqlConnection(connectionString);

try

{

// Попытка открытия соединения.

con.Open();

lblInfo.Text = "<b>Server Version:</b> " + con.ServerVersion;

lblInfo.Text += "<br /><b>Connection Is:</b> " + con.State.ToString();

}

catch (Exception err)

{

// Обработка ошибки с отображением информации.

lblInfo.Text = "Error reading the database. ";

lblInfo.Text += err.Message;

}

finally

{

// В любом случае убедиться, что соединение правильно закрыто.

// Даже если оно не было открыто успешно.

// вызов Close() не вызовет ошибки.

con.Close();

lblInfo.Text += "<br /><b>Now Connection Is:</b>";

lblInfo.Text += con.State.ToString();

}

На рис. 7.2 показани результати роботи цього коду.

Рис. 7.2. Тестування з'єднання

З'єднання – обмежений серверний ресурс. Це означає, що відкривати з'єднання потрібно якомога пізніше, а звільняти – якнайшвидше. У попередньому прикладі коду обробник виключення побудований так, щоб гарантувати, що навіть якщо виникне непередбачене необроблене виключення, все одно з'єднання буде закрито у блоці finally. Якщо не використовувати такий підхід, то у випадку необробленого виключення з'єднання залишиться відкритим до тих пір, поки збирач сміття не знищить об'єкт SqlConnection.

Альтернативний підхід полягає у тому, щоб помістити доступ до даних у блок using. Оператор using декларує, що знищуваний об'єкт використовується протягом короткого періоду часу. Щойно блок using завершиться, CLR негайно звільняє відповідний об'єкт, викликаючи метод Dispose(). Цікаво, що виклик Dispose() для об'єкта Connection відповідає виклику Close(). Це означає, що можна переписати попередній приклад більш компактно наступним чином:

string connectionString =

WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

SqlConnection con = new SqlConnection(connectionString);

using (con)

{

con.Open();

lblInfo.Text = "<b>Server Version:</b> " + con.ServerVersion;

lblInfo.Text += "<br /><b>Connection Is:</b> " + con.State.ToString();

}

lblInfo.Text += "<br /><b>Now Connection Is:</b> ";

lblInfo.Text += con.State.ToString();

Найкраще тут те, що не треба писати блок finally – оператор using звільняє використовуваний об'єкт, навіть при виході з блоку в результаті необробленого виключення.

Організація пулу з'єднань. Отримання з'єднання вимагає короткого, але визначеного часу. У Web-застосуванні, в якому ефективно обробляються запити, з'єднання будуть відкриватися і закриватися нескінченно – у міру обробки нових запитів. У цьому середовищі невеликі накладні витрати на встановлення з'єднання стають досить відчутними, і обмежують масштабованість системи.

Одним з рішень проблеми може бути організація пулу з'єднань. Пул з'єднань – це практика зберігання постійного набору відкритих підключень до БД, які розділяються між сеансами, що використовують одне й те же джерело даних. Це дозволяє уникнути необхідності у постійному створенні і знищенні з'єднань. Пули з'єднань в ADO.NET повністю прозорі для програміста і код доступу до даних не потребуватиме ніяких змін. Коли клієнт запитує з'єднання, викликаючи Open(), цей виклик обслуговується безпосередньо з доступного пулу без повторного відкриття. Коли клієнт звільняє з'єднання викликом Close() або Dispose(), воно не закривається, а повертається у пул для обслуговування наступного запиту.

ADO.NET не включає механізму організації пулу з'єднань. Однак більшість провайдерів даних ADO.NET реалізують деяку форму пулу з'єднань. Провайдери даних SQL Server та Oracle реалізують свої власні ефективні алгоритми організації пулів з'єднань. Ці алгоритми реалізовані повністю у керованому коді і, всупереч поширеній хибній думці, не використовують служби рівня підприємства СОМ+. Щоб з'єднання було вдруге використано у SQL Server або Oracle, рядки підключень повинні в точності збігатися. Якщо вони хоч трохи відрізняються, створюється нове подключення у новому пулі.

Порада. Пули з'єднань SQL Server та Oracle використовують механізм повнотекстового порівняння. Це означає, що будь-яка мінімальне зміна у рядку з'єднання порушує пул, навіть якщо в ньому просто змінюється порядок параметрів або додається додатковий пробіл у кінці. З цієї причини важливо не кодувати жорстко рядки з'єднань на різних веб-сторінках. Замість цього слід зберігати рядок з'єднання в одному місці – переважно у розділі <connectionString> файлу web.config.

В обох провайдерів даних – SQL Server та Oracle – пули з'єднань включаються і використовуються автоматично. Однак також можна використовувати параметри рядка з'єднання для налаштування розмірів пулу. Ці параметри описані в табл. 7.2.

Таблиця 7.2. Налаштування пулів з'єднань.

Налаштування

Опис

Мax Pool Size

Максимальна кількість з'єднань, дозволених у пулі (за промовчанням 100). Якщо досягається максимальний розмір пулу, будь-які наступні спроби відкрити з'єднання поміщаються у чергу в очікуванні звільнення з'єднання. (Якщо час тривалістю Connection.Timeout закінчується перед тим, як звільниться таке з'єднання, виникає помилка.)

Мin Pool Size

Мінімальна кількість з'єднань, які повинні залишатися у пулі (за промовчанням 0). Це число з'єднань буде створено при першому відкритті з'єднання, що скорочує час очікування при першому зверненні.

Pooling

При значенні true (за промовчанням) з'єднання виводиться з відповідного пулу, або за необхідності створюється та додається до відповідного пулу.

Connection Lifetime

Специфікує часовий інтервал у секундах. Якщо з'єднання повернуто в пул і його час підключення перевищив зазначений час життя, воно буде зруйноване. За промовчанням прийняте значення 0, що відключає таку поведінку. Цей засіб зручний, коли необхідно повторно використовувати велику кількість з'єднань за раз.

Нижче показаний приклад рядка з'єднання, що встановлює мінімальний розмір пулу:

SqlCommand cmd = new SqlCommand();

cmd.Connection = con;

cmd.CommandType = CommandType.Text;

cmd.CommandText = "SELECT * FROM Employees";

Деякі провайдери включають методи очищення пулу з'єднань. Наприклад, за допомогою SqlConnection можна викликати статичні методи ClearPool() та ClearAllPools(). При виклику ClearPool() застосовується SqlConnection і всі відповідні з'єднання видаляються. ClearAllPools() ж очищує всі пули з'єднань у поточному домені застосування. (Технічно ці методи не закривають з'єднання. Вони просто позначають їх як недійсні, тому після закінчення тайм-ауту вони будуть закриті під час звичайного очищення з'єднань, кількома хвилинами пізніше.). Ця функціональність рідко використовується, зазвичай єдиний випадок, коли це має сенс – коли відомо, що пул повний або підключення стали недійсними (наприклад, в результаті перезапуску SQL Server), і необхідно уникнути появи помилок.

Порада. Пули з'єднань SQL Server і Oracle завжди підтримуються як частина глобальних ресурсів домена застосування. В результаті цього всі з'єднання губляться, якщо домен програми перезапускається (наприклад, через поновлення або у разі досягнення деякого порогового значення). З тієї ж причини пули з'єднань не можуть повторно використовуватися між різними веб-застосуваннями на одному й тому ж Web-сервері, або між Web-застосуваннями та іншими застосуваннями .NET.

Статистика з'єднань. При застосованні провайдера даних SQL Server можна отримати деяку цікаву статистичну інформацію, використовуючи метод SqlConnection.RetrieveStatistics() (новий у .NET 2.0). Цей метод повертає хеш-таблицю з різними низькорівневими деталями, які дозволяють проаналізувати продуктивність команд і обсяг виконаної роботи. Статистика з'єднання нечасто використовується у розгорнутих застосуваннях, але вельми корисна для діагностики продуктивності на стадії тестування та профілювання. Наприклад, вона передбачає один інструмент, який можна використовувати для визначення того, як застосовуються різні стратегії доступу до даних (інші інструменти включають адміністративні утиліти SQL Server, такі як SQL Profiler та Query Analyzer).

За промовчанням статистика з'єднань відключена для підвищення продуктивності. Щоб використовувати цю статистику, необхідно встановити властивості SqlConnection.StatisticsEnabled рівним true. Це повідомляє класу SqlConnection про необхідність збирати інформацію про кожну виконувану дію. Після цього у будь-який момент ви можете викликати метод RetrieveStatistics(), щоб перевірити цю інформацію, або використати ResetStatisties() для її очищення і початку накопичення "з нуля".

У наступному прикладі відображається кількість байт, отриманих з'єднанням з моменту включення статистики:

Hashtable statistics = con.RetrieveStatistics();

lblBytes.Text = "Retrieved bytes: " + statistics["BytesRetrieved"].ToString();

Статистика представлена у формі довільної колекції пар "ім'я-значення". Це означає, що для отримання значення статистичного показника необхідно знати його специфічне ім'я. Повний список показників можна знайти в документації MSDN, а нижче наведемо кілька найбільш використовуваних:

ServerRoundtrips – вказує кількість звернень з'єднання до сервера БД. Зазвичай це значення відповідає кількості виконаних команд, але на нього можуть вплинути такі стратегії, як пакетування команд.

ConnectionTime – вказує сумарний час знаходження з'єднання у відкритому стані.

BytesReceived – вказує загальну кількість байт, отриманих від сервера БД (як накопичений результат усіх виконаних команд).

SumResultSets – показує кількість виконаних запитів.

SelectRows – записує загальну кількість рядків, отриманих у кожному виконаному запиті.

Класи команд Command і DataReader

Клас Command дозволяє виконати SQL-оператор будь-якого типу. Хоча можна використовувати клас Command для виконання завдань визначення даних (таких як створення і зміна БД, таблиць та індексів), все ж ймовірніше його використання для виконання завдань маніпулювання даними (на зразок отримання та оновлення записів у таблиці).

Специфічні для провайдера класи Command реалізують стандартну функціональність, як і класи Connection. У даному випадку базовий набір методів Command, використовуваних для виконання команд по відкритому з'єднанню, визначається інтерфейсом IDbCommand.

Основи команд. Перш, ніж використовувати команду, необхідно вибрати її тип, встановити її текст і прив'язати до з'єднання. Всю цю роботу можна виконати, встановивши значення відповідних властивостей (CommandType, CommandText та Connection), або передати необхідну інформацію в аргументах конструктора.

Текстом команди може бути SQL-оператор, збережена процедура або ім'я таблиці. Все це залежить від типу використовуваної команди. Існує три типи команд, які перераховані у табл. 7.3.

Таблиця 7.3. Значення перерахування CommandType

Значення

Опис

CommandType.Text

Команда буде виконувати прямий оператор SQL. Оператор SQL вказується у властивості CommandText. Це значення за промовчанням.

CommandType.StoredProcedure

Ця команда буде виконувати збережену процедуру у джерелі даних. Властивість CommandText представляє ім'я процедури.

CommandType.TableDirect

Команда буде опитувати всі записи таблиці. CommandText  ім'я таблиці, з якої команда отримає усі записи. (Ця опція присутня лише для зворотної сумісності з деякими драйверами OLE DB. Вона не підтримується провайдером даних SQL Server і не працює так добре, як ретельно спрямований запит.)

Наприклад, нижче показано, як можна створити об'єкт Command, який представляє запит:

SqlCommand cmd = new SqlCommand();

cmd.Connection = con;

cmd.CommandType = CommandType.Text;

cmd.CommandText = "SELECT * FROM Employees";

А ось більш ефективний спосіб використання одного конструктора Command. Зверніть увагу, що не потрібно специфікувати CommandType, оскільки CommandType.Text приймається за промовчанням:

SqlCommand cmd = new SqlCommand("SELECT * FROM Employees", con);

Альтернативно для використання збереженої процедури слід використовувати наступний код:

SqlCommand cmd = new SqlCommand("GetEmployees", con);

cmd.CommandType = CommandType.StoredProcedure;

У цих прикладах об'єкт Command лише визначається, а не виконується. Об'єкт Command надає три методи, які можна застосувати для виконання команди, в залежності від того, чи необхідно отримати повний результуючий набір, одне значення або просто виконати не запитну команду. Ці методи перераховані у табл. 7.4.

Таблиця 7.4. Методи Command

Значення

Опис

ExecuteNonQuery()

Виконує команди, відмінні від SELECT, такі як SQL-оператори вставки, видалення або оновлення записів. Значення, що повертається, означає кількість рядків, оброблених командою.

ExecuteScalar()

Виконує запит SELECT і повертає значення першого поля першого рядка з набору рядків, згенерованого командою. Цей метод зазвичай застосовується при виконанні агрегатної команди SELECT, що використовує функції накшталдт COUNT() або SUM() для обчислення одного значення.

ExecuteReader()

Виконує запит SELECT і повертає об'єкт DataReader, який є оболонкою однонаправленого курсора, доступного тільки для читання.

Клас DataReader дозволяє читати дані, повернуті командою SELECT, порядково в односпрямованому, доступному лише для читання потоці. Іноді його називають курсором у вигляді "пожежного шлангу". Застосування DataReader – найпростіший шлях отримання даних, але йому бракує можливостей сортування та зв'язування автономного DataSet, який розглядається пізніше. Однак DataReader представляє найбільш швидкий спосіб осмисленого доступу до даних. У табл. 7.5 перераховані основні методи DataReader.

Таблиця 7.5. Методи DataReader.

Значення

Опис

Read()

Переміщує курсор рядка на наступний рядок у потоці. Цей метод також викликається перед читанням першого рядка даних. (Коли DataReader створюється вперше, курсор рядка позиціонується безпосередньо перед першим рядком). Метод Read() повертає true, якщо існує наступний рядок для читання, або false, якщо прочитана остання рядок у наборі.

GetValue()

Повертає значення, збережене в полі з вказаним ім'ям стовпця або індексом, всередині поточної вибраного рядка. Тип повернутого значення – найближчий тип .NET, який найбільш відповідає "рідному" значенню, що зберігається у джерелі даних. Якщо звернутися до поля за індексом і ненавмисно передати невірний індекс, що посилається на неіснуюче поле, то згенерується виключення IndexOutOfRangeException. Можна отримати значення за іменем, що трохи менш ефективно, оскільки у цьому випадку DataReader повинен виконати пошук для знаходження стовпця з вказаним ім'ям.

GetValues()

Зберігає значення поточного рядка у масиві. Кількість збережених полів залежить від розміру масиву, переданого цьому методу. Можна використовувати властивість DataReader.FieldCount для визначення наявної кількості полів у рядку і використовувати цю інформацію для створення масиву потрібного розміру, якщо необхідно зберегти в ньому усі поля.

GetInt32(), GetChar(), GetDateTime(), GetXxx()

Ці методи повертають значення поля з вказаним індексом у поточному рядку, причому тип даних специфікується ім'ям методу. При спробі присвоїти повернене значення змінній невірного типу генерується виключення InvalidCastException.

NextResult()

Якщо команда, яка згенерувала DataReader, повернула більше одного набору рядків, цей метод переміщає курсор на наступний набір рядків і встановлює його безпосередньо перед першим рядком.

Close()

Закриває модуль читання. Якщо вихідна команда запустила збережену процедуру, яка повернула вихідне значення, це значення можна прочитати з відповідного параметра після закриття модуля читання.

Метод ExecuteReader() та DataReader. У наступному прикладі створюється проста команду запиту, яка повинна повернути всі записи з таблиці Employees бази даних Northwind. Команда створюється при завантаженні сторінки.

protected void Page_Load (object sender, System.EventArgs e)

{

// Створити об’єкти Command та Connection.

string connectionString =

WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

SqlConnection con = new SqlConnection(connectionString);

string sql = "SELECT * FROM Employees";

SqlCommand cmd = new SqlCommand(sql, con);

...

Примітка. Цей запит SELECT використовує шаблонний символ *, щоб витягти всі поля, але в реальному коді слід витягувати лише ті поля, які необхідні, щоб уникнути витрат часу на отримання непотрібних даних. Гарною ідеєю є також обмеження кількості повернених записів за допомогою конструкції WHERE, якщо не потрібні всі рядки таблиці.

З'єднання відкривається, і команда виконується за допомогою методу ExecuteReader(), який повертає SqlDataReader, як показано нижче:

// Відкрити Connection та отримати DataReader.

con.Open();

SqlDataReader reader = cmd.ExecuteReader();

Отримавши DataReader, можна організувати цикл для проходження по його записах, викликаючи метод Read() у тілі циклу. Він переміщує курсор рядка на наступний запис (при першому виклику – на перший рядок). Метод Read() також повертає булеве значення, що означає наявність наступних рядків для читання. У наступному прикладі цикл продовжується до тих пір, поки Read() не поверне false, після чого елегантно завершується.

Інформація з кожного запису потім об'єднується в один довгий рядок. Щоб забезпечити швидке виконання маніпуляцій з рядками, замість звичайних об'єктів рядків використовується StringBuilder (з простору імен System.Text).

// Пройти у циклі по записах та побудувати HTML-рядок

StringBuilder htmlStr = new StringBuilder("");

while (reader.Read())

{

htmlStr.Append("<li>");

htmlStr.Append(reader["TitleOfCourtesy"]);

htmlStr.Append(" <b>");

htmlStr.Append(reader.GetString(1));

htmlStr.Append("</b>, ");

htmlStr.Append(reader.GetString(2));

htmlStr.Append(" - employee from ");

htmlStr.Append(reader.GetDateTime(6).ToString("d"));

htmlStr.Append("</li>");

}

...

Код читає значення поля TitleOfCourtesy, звертаючись до нього за іменем, через індексатор Item. Оскільки властивість Item – індексатор за промовчанням, не потрібно явно включати ім'я властивості Item при отриманні значення поля. Далі код читає поля LastName та FirstName, викликаючи GetString() з індексом поля 1 і 2 у даному випадку). І, нарешті, код звертається до поля HireDate, викликаючи метод GetDateTime() з індексом поля, що дорівнює 6. Всі ці підходи еквівалентні і включені сюди для демонстрації підтримуваних варіантів.

Примітка. У цьому прикладі StringBuilder забезпечує значне збільшення продуктивності. Якщо замість цього використовувати операцію + для конкатенації рядків, то вона кожен раз буде руйнувати і створювати новий рядковий об'єкт. Ця операція виконується помітно повільніше, особливо над довгими рядками. Об'єкт StringBuilder дозволяє уникнути цієї проблеми за рахунок виділення буфера пам'яті для символів.

І завершальний крок – закриття модуля читання, закриття з'єднання і відображення згенерованого тексту у серверному елементі керування:

reader.Close();

con.Close();

HtmlContent.Text = htmlStr.ToString();

}

Якщо запустити цю сторінку, то отримаємо результат, показаний на рис 7.3. На більшості сторінок ASP.NET не треба використовувати такий трудомісткий підхід для відображення даних на Web-сторінці. Замість цього можна використовувати елементи керування, що працюють з даними, які описані у наступних лекціях. Проте при написанні коду доступу до даних у компоненті БД, ймовірніше, буде використовуватися DataAdapter.

Рис. 7.3. Отримання результатів за допомогою DataReader

CommandBehavior. Метод ExecuteReader() має перевантажену версію, яка приймає як параметр одне зі значень перерахування CommandBehavior. Одне з часто використовуваних його значень  CommandBehavior.CloseConnection. Якщо це значення передається ExecuteReader(), DataReader закриває асоційоване з ним з'єднання, як тільки закривається сам DataReader. Застосовуючи цю техніку, можна переписати код наступним чином:

SqlDataReader reader = cmd.ExecuteReader(CommandBehavior.CloseConnection);

// (Здесь строится строка HTML)

//Не нужно закрывать соединение. Просто закрываем модуль чтения.

reader.Close();

HtmlContent.Text = htmlStr.ToString();

Така поведінка особливо зручна, якщо DataReader витягається в одному методі і при цьму необхідно передати його на обробку іншому методу. При використанні значення CommandBehavior.CloseConnection з’єднання буде закрито автоматично, щойно другий метод закриє об'єкт DataReader.

Інше допустиме значення  CommandBehavior.SingleRow  підвищує продуктивність виконання запиту, коли потрібно витягти один єдиний рядок. Наприклад, якщо витягається єдиний запис, використовуючи унікальне значення первинного ключа (CustomerlD, ProductID тощо), то можна застосувати цю оптимізацію. Можна також використовувати CommandBehavior.SequentialAccess для читання частини двійкового поля, що знижує витрату пам'яті при читанні великих двійкових полів.

Інші значення перерахування застосовуються рідше, тому вони не розглядаються. Повний список можна знайти у документації по .NET.

Метод ExecuteScalar() повертає значення, збережене у першому полі першого рядка результуючого набору, згенерованого запитом SELECT команди. Цей метод зазвичай застосовується для виконання запитів, що повертають одне єдине поле, можливо, обчислене агрегатною функцією SQL, наприклад, СOUNT() або SUM().

Наступний приклад демонструє, як можна з таким підходом отримати (і вивести на сторінці) кількість записів таблиці працівників:

SqlConnection con = new SqlConnection(connectionString);

string sql = "SELECT COUNT(*) FROM Employees";

SqlCommand cmd = new SqlCommand(sql, con);

// Открыть соединение и получить значение COUNT(*).

con.Open();

int numEmployees = (int)cmd.ExecuteScalar();

con.Close();

// Отобразить информацию.

HtmlContent.Text += "<br />Total employees: <b>" +

numEmployees.ToString() + "</b><br />";

Код досить простий, але варто відзначити, що необхідно привести повернене значення до правильного типу, оскільки ExecuteScalar() повертає об'єкт.

Метод ExecuteNonQuery() виконує команди, які не повертають результуючих наборів, такі як INSERT, DELETE або UPDATE.

Метод ExecuteNonQuery() повертає лише кількість оброблених записів.

Унаведеному нижче прикладі використовується команда DELETE та динамічно будується SQL-рядок:

SqlConnection con = new SqlConnection(connectionString);

string sql = "DELETE FROM Employees WHERE EmployeeID = " + empID.ToString();

SqlCammand cmd = new SqlCommand(sql, con);

try

{

con.Open();

int numAff = cmd.ExecuteNonQuery();

HtmlContent.Text +=

string.Format("<br />Deleted <b>{0}</b> record(s)<br />", numAff);

}

catch (SqlException exc)

{

HtmlContent.Text += string.Format("<b>Error:</b> {0}<br/><br/>", exc.Message);

}

finally

{

con.Close();

}

Застосування параметризованих команд. Параметризована команда – це команда, яка використовує символи-заповнювачі у тексті SQL. Заповнювач вказує місце для динамічно застосовуваних значень, які потім пересилаються через колекцію Parameters об'єкту Command.

Наприклад, наступний оператор SQL:

SELECT * FROM Customers WHERE CustomerID = 'ALFKI'

повинен стати чимось на зразок:

SELECT * FROM Customers WHERE CustomerID = @CustID

Заповнювачі додаються роздільно і автоматично кодуються.

Синтаксис параметрезованих команд злегка відрізняється у різних провайдерів. Провайдер SQL Server передбачає іменовані заповнювачі (з унікальними іменами). У провайдера OLE DB кожне жорстко закодоване значення замінюється знаком питання. У будь-якому випадку необхідно застосувати об'єкт Parameter для кожного параметра, який вставляється в колекцію Command.Parameters. При роботі з провайдером OLE DB слід переконатися, що параметри додаються у тому ж порядку, в якому вони з'являються у рядку SQL. Цього не вимагає провайдер даних SQL Server, оскільки відповідність між параметрами та заповнювачами задається за допомогою імен.

У наступному прикладі наведено варіант колишнього запиту, що виключає можливість атаки впровадженням:

string connectionString =

WebConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;

SqlConnection con = new SqlConnection(connectionString);

string sql =

"SELECT Orders.CustomerID, Orders.OrderID, COUNT(UnitPrice) AS Items, " +

"SUM(UnitPrice * Quantity) AS Total FROM Orders " +

"INNER JOIN [Order Details] " +

"ON Orders.OrderID = [Order Details].OrderID " +

"WHERE Orders.CustomerID = @CustID " +

"GROUP BY Orders.OrderID, Orders .CustomerID";

SqlCommand cmd = new SqlCommand(sql, con);

cmd.Parameters.Add("@CustID", txtID.Text);

con.Open();

SqlDataReader reader = cmd.ExecuteReader();

GridView1.DataSource = reader;

GridView1.DataBind();

reader.Close();

con.Close();

Якщо зробити спробу атаки впровадженням SQL з цією виправленою версією сторінки, то виявиться, що вона не поверне жодних записів. Це тому, що жодна позиція замовлення не має значення ідентифікатора замовника, рівного текстовому рядку ALFKI 'OR '1' = '1.


 

А также другие работы, которые могут Вас заинтересовать

17765. Дослідження мікроклімату у виробничих приміщеннях 228.5 KB
  Лабораторна робота №11 Дослідження мікроклімату у виробничих приміщеннях Мета роботи ознайомитись з основними параметрами мікроклімату у виробничих приміщеннях з їх оптимальними та допустимими значеннями набути практичних навичок у користуванні нормативними д...
17766. Дослідження освітлення 370.5 KB
  Лабораторна робота № 1. Дослідження освітлення. Мета роботи: ознайомитися з видами освітлення і з нормами проектування природного і штучного освітлення; дослідити нормовані показники що характеризують освітлення в умовах лабораторії; вивчити і дослідити джерела...
17767. Технічні випробування системи вентиляції 648.5 KB
  Лабораторна робота № 8 Технічні випробування системи вентиляції Мета роботи освоїти методику і набути навичок випробування системи вентиляції. Ефективним засобом нормалізації повітря робочої зони виробничих приміщень є вентиляція. Вентиляцією називається...
17768. Дослідження параметрів виробничого шуму і визначення ефективності звукоізоляції 282 KB
  Лабораторна робота № 12. Дослідження параметрів виробничого шуму і визначення ефективності звукоізоляції. Мета роботи: вивчити методику виміру і оцінки основних параметрів виробничого шуму; дослідити звукоізоляційні властивості різних матеріалів. Зага...
17769. Інтернет – як засіб інформаційної підтримки роботи вчителя 94 KB
  Інтернет – як засіб інформаційної підтримки роботи вчителя Організація мережі Інтернет. Перегляд інформаційних ресурсів в Інтернеті Доступ користувачів до мережі Інтернет. Робота з пошуковими серверами електронними бібліотеками. Пошук потрібних нових гр...
17770. Основні вимоги до створення навчальної презентації 51.5 KB
  Основні вимоги до створення навчальної презентації План Визначення поняття €œ Презентація €. Типи презентацій. Алгоритм створення презентацій. Вимоги до структури та змісту презентації. Вимоги до оформлення змісту презентації за Д. Льюїсом. ...
17771. Інформаційні технології в освіті 94.5 KB
  Інформаційні технології в освіті. План 1.Походження терміну Інформація. Поняття інформації. Види інформації. Форми подання. Інформаційні процеси. 2. Визначення основних термінів курсу: технологія інформаційна технологія ІТ інфор...
17772. Основні напрямки використання ІКТ в навчальній діяльності на уроках іноземних мов 64.5 KB
  Лекція 4. Основні напрямки використання ІКТ в навчальній діяльності на уроках іноземних мов. Педагогічні програмні засоби їх класифікація. Підготовка вчителя до уроку з використанням ППЗ Основні форми використання ППЗ на різних етапах уроку. Організ
17773. Використання можливостей MS Excel у роботи вчителя. Розробка електронного навчального модуля 281.5 KB
  Лабораторна робота № 3 Тема. Використання можливостей MS Excel у роботи вчителя. Розробка електронного навчального модуля. II частина – Перевірка. Мета . Оволодіння навичками використання MS Excel у роботі : створення тестів для перевірки знань та при підготовці до ба...