Visual Studio 2005 і SQL Server 2005: краще разом

1. Спрощення процесу створення додатків для бази даних
2. Подорож на MARS
3. CLR в SQL Server
4. Удосконалення механізму розподілених транзакцій
5. Пора за роботу

Спрощення процесу створення додатків для бази даних

Повторна затримка виходу SQL Server 2005 і Visual Studio 2005 надала адміністраторам баз даних (DBA) і розробникам додатковий час для того, щоб попрацювати з бета-версіями обох продуктів, а також осмислити те, як оновлені інструментальні засоби можуть змінити сам процес створення додатків. Я дуже рекомендую почати використовувати нові можливості при проектуванні і плануванні програм прямо зараз, не чекаючи виходу офіційних версій. Це дозволить отримати додатки, які відразу зможуть використовувати всі переваги, що забезпечуються новими продуктами.

Розглянуті в статті приклади працюють з Visual Studio 2005 Beta 2 і SQL Server 2005 Beta 3 та використовують тестову базу даних Adventure Works, яка поставляється разом з SQL Server 2005. Для спрощення настройки рядка з'єднання SQL Server 2005 і Visual Studio 2005 було встановлено на один і той же комп'ютер. Для того щоб зробити ці приклади більш функціональними, я наведу кілька збережених процедур і деякі додаткові дані. Все це можна встановити на стандартну базу AdventureWorks, скориставшись програмою, код якої показаний в лістингу 1 .

Подорож на MARS

Одним з найбільш примітних нововведень в SQL Server 2005 є MARS (це і одна з кращих абревіатур, придуманих в Редмонді за останній час). Основна ідея MARS полягає в тому, щоб користувачі не були обмежені необхідністю послідовно вводити команди в ході з'єднання з базою даних. Замість цього з'єднання має допускати одночасну обробку декількох команд. Тепер, з появою MARS, розробники в рамках одного з'єднання можуть використовувати кілька команд для роботи з активною базою даних або (що більш важливо) мати кілька результуючих наборів даних або курсорів на стороні сервера, що працюють одночасно.

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

Переваги MARS стосуються не тільки продуктивності і масштабованості: при використанні цієї технології спрощується і код розроблюваних програмних засобів. на лістингу 2 міткою A позначений фрагмент коду, який створює один об'єкт з'єднання (connection), який потім використовує команди читання (reader) і відновлення (update). Коли виконується операція читання і витягуються дані по кожному рядку, для них відразу ж виконується операція оновлення. Весь цей процес відбувається в межах одного з'єднання. Якщо спробувати одночасно організувати доступ до даних і їх оновлення в середовищі Visual Studio 2003 або SQL Server 2000, важливо переконатися, що цей тип простого послідовного оновлення, заснований на використанні курсорів на стороні сервера, працювати не буде. Необхідно також врахувати, що, якщо ви захочете відкомпілювати код лістингу 2 в Visual Studio 2003 перед цим з нього слід прибрати трансакціонної логіку, властиву Visual Studio 2005.

CLR в SQL Server

Якщо MARS являє собою розширення, з приводу якого було не надто багато шуму і яке не вимагає настройки, то CLR - зовсім інша справа. Інтеграція CLR в SQL Server 2005 була, мабуть, найбільш спірним питанням, що стосуються розширення SQL Server. Але в той же час це, напевно, одне з найбільш значних удосконалень. Основні сумніви з приводу CLR були пов'язані з тим, щоб зрозуміти, коли його використовувати, а коли ні.

Необхідно відзначити, що CLR в SQL Server не є заміною T-SQL. І хоча з маркетингової інформації Microsoft слід, що тепер потрібно використовувати тільки мови .NET, на презентаціях для технічних фахівців нерідко говорять про те, що в більшості запитів застосування T-SQL поки є більш ефективним, ніж використання CLR. За допомогою цих двох, здавалося б, протилежних позицій технічна служба Microsoft хоче дати чіткі рекомендації про те, як правильно використовувати CLR в SQL Server 2005, а не вселити клієнтам побоювання з приводу CLR.

У порівнянні з T-SQL, мова CLR має ряд специфічних переваг. Перше з них полягає в можливості створення функцій, які виробляють інтенсивну обробку. За допомогою CLR можна створювати функції, які інкапсулюють деякі бізнес-обчислення всередині бази даних. Якщо такі функції використовуються саме для обчислень (а не для отримання даних), то в цьому випадку використання CLR забезпечить виграш в продуктивності щодо T-SQL. Ще однією перевагою застосування CLR в SQL Server є те, що він може обробляти складні конструкції XML. Крім того, CLR дозволяє створювати нестандартні типи, визначені користувачем (User Defined Type, UDT). І останнє: використання CLR дозволить відмовитися від дотеперішніх і небезпечних розширених збережених процедур. На відміну від розширених збережених процедур, виконання яких могло виходити з-під контролю SQL Server, CLR за замовчуванням налаштований так, що гарантується виконання використовуваних розширень T-SQL в поточному контексті безпеки. А зараз розглянемо, як можна створювати нестандартні UDT для подальшого використання в додатку.

Оскільки для нормального функціонування баз даних не потрібні будь-які механізми CLR, за замовчуванням в SQL Server 2005 компонент CLR відключений. Тому, для того щоб задіяти можливості CLR, перш за все його потрібно включити. Для цього потрібно відкрити вікно Query в SQL Management Studio та перенести туди наведену нижче команду запуску стандартної процедури, що T-SQL sp_configure.

Дана інструкція T-SQL включає механізм CLR і повертає поточні параметри конфігурації бази даних. Більш детальна інформація про команду sp_configure міститься в документації Microsoft.

Після включення CLR можна приступати до створення UDT за допомогою Visual Studio 2005. Відповідний код може бути реалізований як на Visual Basic, так і на C #, в даному прикладі я скористався Visual Basic. Спочатку створюється новий проект, для цього зі списку типів проектів Visual Basic вибирається шаблон SQL Server Project. Після присвоєння проекту імені (я назвав його SQLServerUDT) Visual Studio попросить додати посилання на базу даних (відповідне діалогове вікно наведено на екрані 1). В даному діалоговому вікні необхідно вказати ім'я провайдера (в нашому прикладі потрібно .NET Framework Data Provider for SQL Server). Потім в діалоговому вікні New Database Reference (екран 2) потрібно вказати базу даних відповідного проекту. Введення значення local в текстове поле Server name вказує на локальний SQL Server 2005, встановлений на даному комп'ютері, який Visual Studio потім асоціює з відповідним проектом.

Отже, новий проект створений, тепер можна додати клас, що представляє наш UDT. Слід клацнути на проекті правою кнопкою миші і вибрати з контекстного меню пункт Add User Defined Type. Відкриється нове діалогове вікно, що містить кілька типів класів, які можуть бути додані в даний проект. Необхідно вибрати встановлений за замовчуванням клас User Defined Type і змінити заданий за замовчуванням ім'я файлу на myPointType.vb. Після натискання OK буде згенеровано код, показаний в лістингу 3 .

Тут видно, що код, згенерований для даного класу використовується за умовчанням шаблоном, містить в самому низу опису приватних (private) властивостей цього нового класу. Я не буду тут докладно зупинятися на тому, як реалізувати покажчик типу, досить знати, що він складається з двох цілих чисел, які за допомогою даного UDT можуть бути збережені як одне значення. В лістингу 4 показано, як виглядає вихідний файл myPointType.vb після того, як вказівником типу було дано це просте визначення. Зверніть увагу, що стандартна реалізація доповнена компонентом Regions, який допускає згортання, таким чином, можна групувати пов'язані один з одним частини при реалізації даного типу.

Тепер, коли у нас є створений оновлений клас, наступний крок - компіляція даного класу. В результаті буде створений файл c розширенням .DLL, доступний для будь-якого з проектів, в якому використовується посилання на створений нами тип, але для цього спочатку потрібно розмістити новий тип в SQL Server. Це можна зробити двома способами. Для розроблюваної бази даних (але не для промислово експлуатованої) можна використовувати функцію Deploy пакета Visual Studio. Для цього потрібно перейти в меню Build, вибрати пункт Deploy, і Visual Studio автоматично скомпілює ваш UDT і розмістить його в тій базі даних SQL Server, на яку було посилання.

Другий метод розміщення UDT придатний як для розроблюваних, так і для промислових баз даних і полягає у використанні команд T-SQL. Послідовність команд T-SQL, що використовується для установки створеного UDT на SQL Server, наведена в лістингу 5 . Тут вказано шлях до каталогу, відповідний моєму локального комп'ютера, перед запуском команд на іншій машині необхідно відповідним чином змінити опис шляху. Для того щоб розпізнавати даний тип, SQL Server і наявне додаток повинні посилатися на цю збірку.

Щоб скористатися новоствореним типом, потрібно зробити посилання на нього, а потім створити параметр для збереженої процедури типу UDT.

Отже, це було короткий вступ, що дозволяє засвоїти основні принципи створення за допомогою .NET CLR нестандартного UDT, який буде розпізнаватися і вашою базою даних, і створеним додатком. У міру накопичення досвіду роботи з CLR ви навчитеся використовувати можливості XML для подальшого розширення функціональності створюваних типів.

Удосконалення механізму розподілених транзакцій

При роботі з .NET і підключенні до SQL Server з помощьюVisual Studio більш ранньої версії, ніж 2005, і одночасному вимозі, щоб транзакція зачіпала кілька джерел даних (цей механізм також відомий як автоматична транзакція), доведеться спочатку розмістити компоненти .NET в просторі імен Enterprise Services .NET, а потім інтегрувати збірки .NET з COM +. З випуском Visual Studio 2005 цей процес спростився, що обумовлено появою нового простору імен, званого System.Transactions. (Дане простір імен описується в документації Microsoft, доступною за адресою: http://msdn2.microsoft.com/library/ system.transactions.aspx або в MSDN в розділі .NET Framework Class Library.) Для управління транзакціями розробники можуть використовувати три основні класи простору System.Transactions. До них відносяться Transaction, TransactionScope і TransactionManager.

У середовищі .NET 1.1 для виклику методу BeginTransaction використовується об'єкт Connection. Якщо задіяти цей метод в разі з'єднання з SQL Server, то об'єкт Connection поверне об'єкт System.Data.SqlClient.SqlTransaction. Цей об'єкт потім може бути асоційований з кожною з команд, яка є складовою частиною даної транзакції. Повторні виклики, що виконуються SQL Server, все одно справляють неявні транзакції, тому об'єкт, відповідний транзакції, потрібен лише для того, щоб об'єднати в одну групу кілька команд.

Коли викликається метод Begin Transaction, ADO.NET використовує для звернення до SQL Server існуючий обліковий запис і запускає на виконання команду T-SQL Begin Transaction. Таким чином, щоб використовувати метод BeginTransaction, потрібно послідовно звертатися до одного й того ж об'єкту, відповідного з'єднанню, для кожної команди, що є частиною даної транзакції, причому даний тип транзакцій несумісний з транзакціями COM +.

Перше, що слід усвідомити щодо використання простору імен System.Transactions, - це те, що можна і раніше створювати в SQL Server ручні транзакції і не вдаватися до методу BeginTransaction. Створена транзакція може як і раніше вважатися ручної, оскільки клієнт не тільки програмує код її початку і завершення, а й асоціює транзакцію з кожної зі складових її команд.

У Visual Studio 2005 з'явився об'єкт System.Transactions.Transaction, за допомогою якого можна вручну включати в транзакцію необхідні команди. У лістингу 2 міткою B відзначений фрагмент коду, який представляє собою приклад створення вручну об'єкта System. Transactions. CommittableTransaction. Об'єкт CommittableTransaction являє собою одну з реалізацій віртуального базового класу Transaction. Спочатку створюється об'єкт Connection, потім встановлюється з'єднання. Після того як з'єднання з базою даних встановлено, об'єкт Connection використовує об'єкт CommitableTransaction для формування транзакції. Ця точка є початком транзакції; починаючи з неї можна виконати одну або кілька команд роботи з базою даних, які будуть частиною даної транзакції. І нарешті, в момент завершення звернення до бази даних ми можемо або виконати (commit) або скасувати (roll back) нашу транзакцію.

На перший погляд можливість ручної прив'язки нового об'єкта транзакції до з'єднання мало чим відрізняється від існуючої логіки транзакцій, але насправді тут докорінно змінюється сама парадигма транзакції. Код, позначений міткою B, створює дійсно розподілену транзакцію, для чого в Visual Studio 2003 треба було б використання Enterprise Services. А в аналізованому нами проекті немає посилань на простір імен System.EnterpriseServices. У Visual Studio 2005 для створення транзакцій, що використовують кілька джерел даних, в розділ посилань проекту необхідно включити тільки бібліотеку System.Transactions. А якщо немає потреби звертатися до Enterprise Services, це означає, що код програм спрощується і немає необхідності інтегрувати свою збірку з COM +. Тепер, перебуваючи в середовищі .NET, можна створювати розподілені транзакції, що використовують кілька з'єднань. Також необхідно пам'ятати, що до завершення транзакції об'єкт, відповідний з'єднанню, повинен залишатися відкритим (хоча він може бути при цьому в «сплячому» (dormant) стані), що ілюструє послідовність команд фрагмента коду даного прикладу.

Звичайно, з появою об'єкта System.Transactions.Transaction процедура управління розподіленими транзакціями спростилася, проте розробники Visual Studio 2005 пішли ще далі і надали нам інструментальні засоби для автоматизації розподілених транзакцій. Об'єкт TransactionScope дає можливість автоматично асоціювати з поточної транзакцією кожен об'єкт з'єднання в межах встановлених кордонів (scope). Як видно з прикладу з міткою C в лістингу 2, код з використанням об'єкта TransactionScope виглядає навіть дещо простіше, ніж код для ручного створення об'єкта System.Transaction.Transaction. Код, позначений міткою C, починається з нового елемента мови Visual Basic - команди Using. Об'єкт TransactionScope завжди слід створювати в контексті команди Using, це гарантує точне визначення меж транзакції. Після цього можна створити і встановити стільки сполук, скільки потрібно, і кожна команда, яка виконується в контексті кордонів активної транзакції, буде автоматично асоціюється з даної транзакцією.

В ході Виконання фрагмента, Позначення міткою C, створюється декілька транзакцій, но, оскількі в даного прікладі вікорістовується только Одне джерело Даних, я залишилась активним ЛИШЕ ОДНЕ з'єднання. У даного прікладі спочатку встановлюється з'єднання и віконується команда Update. На Наступний кроці встановлюється статус транзакції. Зверніть увагу на різніцю между установкою статусу и Виконання транзакції. Коли користувач працює з об'єктом TransactionScope, транзакція НЕ буде Виконувати до тих пір, поки програма НЕ дійде до Пропозиції End Using. Виклики методів Complete або Dispose насправді НЕ завершують и не відкочують транзакцію. Смороду просто вказують на ті, что стане, коли буде досягнуть межа TransactionScope. Якщо замість об'єкта Transaction використовується об'єкт TransactionScope, то в цьому випадку відпадає необхідність у асоціювання різних з'єднань з даної транзакцією, це автоматично зробить .NET.

Третім основним об'єктом простору імен System.Transactions є об'єкт TransactionManager. Даний об'єкт проектувався не стільки для обробки транзакцій, скільки для надання розробникам інтерфейсу до координатора розподілених транзакцій, distributed-transaction coordinator. Опис роботи з цим об'єктом виходить за рамки даної статті, скажу лише, що призначення цього об'єкта полягає в тому, щоб надати розробникам набір статичних методів, які вони могли б використовувати для доступу до одного або декількох менеджерам транзакцій. Таким чином, тепер розробники можуть реєструвати в системі утиліти управління транзакціями, відмінні від тих, які в .NET є за замовчуванням, а це в свою чергу означає, що тепер можна розширити технологію координування транзакцій за рамки COM +.

Пора за роботу

У даній статті ми розглянули лише три нові можливості, якими можна користуватися при роботі з SQL Server 2005 і Visual Studio 2005. У цих продуктах є ще маса механізмів для розширення функціональності створюваних додатків. До них відносяться можливість роботи з XML, створення по-справжньому асинхронних запитів до бази даних і вдосконалена технологія обробки помилок. Одним словом, незалежного від того, хто ви - розробник або адміністратор, настав час починати працювати з цими продуктами. В якості основи для нових розробок вже можна використовувати фінальні версії SQL Server 2005 і Visual Studio 2005.

Вільям Шелдон - Провідний інженер компанії InterKnowlogy, має сертифікати MCSD і MCP + SiteBuilding [email protected]