Засіб візуалізації технології LINQ to SQL

Размещено на http://www.allbest.ru

РЕФЕРАТ

Пояснювальна записка до дипломного проекту «Засіб візуалізації технології LINQ to SQL»: 39 с., 13 рис., 3 табл., 7 інформаційних джерел, 3 додатка.

ORM, LINQ to SQL, БАГАТОШАРОВІСТЬ, SQL, LINQ, .NET, MVC, MVC, MVP, MVVM

Об'єкт розробки - засіб візуалізації технології LINQ to SQL.

Мета проекту - підвищення ефективності навчального процесу, шляхом розробки та застосування засобів візуалізації досліджуваної технології LINQ to SQL.

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

Результати дипломного проектування рекомендується використовувати при навчанні студентів сучасних технологій.



ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ

ПЗ - Програмне забезпечення

ООП - Об'єктно-орієнтоване програмування.

ORM - Об'єктно-реляційне відображення (Object-relational mapping)

LINQ - Мова інтегрованих запитів (Language Integrated Query)

SQL - Мова структурованих запитів (Structured Query Language)

БД - База даних

ООСУБД - Об'єктно-орієнтована система управління базами даних

візуалізація програмний забезпечення



ВСТУП

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

В сучасному житті професія програміст набула високого рівня затребуваності цьому сприяє популярності і масштабність використання інформаційних технологій.

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

Таким чином, метою дипломної роботи є підвищення ефективності навчання студентів. Для досягнення цієї мети, в процесі дипломного проектування, буде проведена розробка та впровадження програмного засобу, що продемонструє можливості та засоби використання технології LINQ to SQL.



РОЗДІЛ 1. ORM В БАГАТОШАРОВІЙ АРХІТЕКТУРІ ЗАСТОСУВАННЯ

1.1 Основна характеристика ORM

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

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

Ключовою особливістю ORM є відображення, яке використовується для прив'язки об'єкта до його даних в БД. ORM як би створює «віртуальну» схему бази даних у пам'яті і дозволяє маніпулювати даними вже на рівні об'єктів. Відображення показує як об'єкт і його властивості пов'язані з однією або кількома таблицями та їх полями в базі даних. ORM використовує інформацію цього відображення для управління процесом перетворення даних між базою і формами об'єктів, а також для створення SQL-запитів для вставки, оновлення та видалення даних у відповідь на зміни, які додаток вносить в ці об'єкти.

Рис. 1.1 Концепція об'єктно-реляційного відображення

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

Засіб об'єктно-реляційного відображення такого рівня являє собою спеціалізовану ООСУБД, мова запитів якої максимально наближений до засобів доступу до даних базової мови програмування, а відповідна SQL-орієнтована база даних використовується тільки як середовище зберігання.

Найбільш масштабним проектом, пов'язаним із забезпеченням розширювальних можливостей об'єктно-реляційного відображення для цілого ряду мов програмування, є LINQ компанії Microsoft. Перші реалізації були виконані для мов C # і Visual Basic.NET [2].

Вирішення проблеми ORM

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

ORM вирішує проблему так званої парадигми «невідповідності», яка говорить про те, що об'єктні та реляційні моделі не дуже добре працюють разом. Реляційні бази представляють дані в табличному форматі, в той час як об'єктно-орієнтовані мови представляють їх як зв'язаний граф об'єктів. Основна проблема і невідповідность виникає під час збереження цього графа об'єктів в реляційну базу або його завантаження:

реляційна модель може бути набагато детальніше, ніж об'єктна;

реляційні СУБД не мають нічого спільного з успадкуванням - природну парадигму об'єктно-орієнтованих мов програмування;

в СУБД визначений тільки один параметр для порівняння записів - первинний ключ;

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

для доступу до даних в ООП використовуються послідовні переходи від батьківського об'єкта до властивостей дочірніх елементів і ініціалізації об'єктів за необхідністю. Такий підхід вважається ефективним способом отримання даних з реляційних баз даних [2, 3].

Використання ORM в проекті позбавляє розробника в необхідності роботи з SQL і написання великої кількості коду, часто одноманітного і з великою кількістю помилок. Весь генерований ORM код добре перевірений і оптимізований, тому не потрібно в цілому замислюється про його тестування. Це безсумнівно є плюсом, але в тей же час не варто забувати і про мінуси. Основний з них - це втрата продуктивності. Це відбувається тому, що більшість ORM призначені для обробки широкого спектру сценаріїв використання даних, набагато більшого, ніж будь-яке окреме застосування зможе використовуватися.

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

Крім того, поряд з проблемою розробки додатків є не менш важлива проблема їх супроводу. Як правило, супроводом додатків займаються не розробники додатків, а зовсім інші люди. Цим фахівцям набагато простіше мати справу з однорідними текстами програм, повністю написаних на одній мові програмування.

Технологія ОRМ має дуже широке використання в сучасному ІТ світі. Зазвичай під час навчання про цю технологію згадають поверхнево, або зовсім не згадують. Доцільність розробки засобу візуалізації, полягає в надані студентам знань та навичок використання технології ОRМ при створенні архітектури розроблювального програмного забезпечення.

Шаблони багатошарової архітектури

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

«Низькорівневі» шаблони, що враховують специфіку конкретної мови програмування, називаються ідіомами. Це гарні рішення проектування, характерні для конкретної мови або програмної платформи, і тому не універсальні.

На найвищому рівні існують архітектурні шаблони, вони охоплюють собою архітектуру всієї програмної системи.

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

Правильно сформульований шаблон проектування дозволяє, відшукати вдале рішення, та використовувати його багаторазово.

Існує багато різних шаблонів проектування які застосовуються в різних ситуаціях. Можна розглянути основні шаблони які найчастіше використовуються.

Модель-Представлення-контролер (Model-view-controller, MVC) -- архітектурний шаблон, який використовується під час проектування та розробки програмного забезпечення.

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

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

Архітектурний шаблон Модель-Представлення-Контролер (MVC) поділяє програму на три частини. модель (Model) - зберігає дані і забезпечує інтерфейс до них. Предствалення (View)- відповідальний за представлення цих даних користувачеві. Контролер (Controller)- керує компонентами, отримує сигнали у вигляді реакції на дії користувача, і повідомляє про зміни компоненту модель. Така внутрішня структура в цілому поділяє систему на самостійні частини і розподіляє відповідальність між різними компонентами що зображено на рис. 1.2.

MVC поділяє цю частину системи на три самостійні частини: введення даних, компонент обробки даних і виведення інформації. Model інкапсулює ядро даних і основний функціонал з їх обробки. Також компонент Model не залежить від процесу введення або виведення даних. Компонент виводу View може мати декілька взаємопов'язаних областей, наприклад, різні таблиці і поля форм, в яких відображається інформація. У функції Controller входить моніторинг за подіями, що виникають в результаті дій користувача (зміна положення курсора миші, натиснення кнопки або введення даних в текстове поле).

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

Рис. 1.2 Концепція Модель-Представлення-Контролер

Модель-представлення-пред'явник (Model-View-Presenter, MVP) - шаблон проектування, похідний від MVC, який використовується в основному для побудови користувальницького інтерфейсу, його зображено на рис 1.3 [1, 3].

У MVP Presenter бере на себе функціональність посередника (граючи роль, аналогічну контролеру в MVC). Крім того, Presenter відповідає за управління подіями користувача інтерфейсу, яке зазвичай було турботою контролера. У підсумку, модель стає суворо моделлю предметної області.

MVP - шаблон проектування користувальницького інтерфейсу, який був розроблений для полегшення автоматичного модульного тестування і поліпшення розподілу відповідальності у презентаційній логіці (відділення логіки від відображення).

Model (моделі) являє собою інтерфейс, що визначає дані для відображення або беруть участь в інтерфейсі іншим чином.

View (представлення) - це інтерфейс, який відображає дані (модель) і маршрутизує користувача команди Presenter, щоб той взаємодіяв з цими даними.

Presenter взаємодіє з моделлю і видом. Він витягає дані з сховища (моделі), і форматує їх для відображення в View (представлення).

Рис. 1.3 Концепція Модель-Вид- Пред'явник

Переглянути визначається як інтерфейс, який Presenter буде використовувати для отримання та установки даних моделі. Коли викликається подія вигляд, воно викликає конкретний метод Presenter який не має параметрів і не має значення, що повертаються. Потім Presenter отримує дані з View, через інтерфейс.

Отримавши дані Presenter викликає методи моделі, і встановлює дані з моделі під View через інтерфейс [1, 3].

Шаблон Model-View-ViewModel - застосовується при проектуванні архітектури застосування.

MVVM використовується для розділення моделі та її подання, тому що дозволяє змінювати їх окремо один від одного.

MVVM зручно використовувати замість класичного MVC і йому подібних у тих випадках, коли в платформі, на якій ведеться розробка, присутній «зв'язування даних». У MVC/MVP зміни в інтерфейсі не впливають безпосередньо на модель, а попередньо йдуть через Контролер/Presenter.

У таких технологіях як WPF і Silverlight є концепція «зв'язування даних», що дозволяє пов'язувати дані з візуальними елементами в обидві сторони. Отже, при використанні цього прийому застосування моделі MVC стає вкрай незручним через те, що прив'язка даних до подання безпосередньо не вкладається в концепцію MVC/MVP.

Патерн MVVM ділиться на три частини, що зображені на рис 1.4. Модель (Model), так само, як у класичній MVC, Модель являє собою фундаментальні дані, необхідні для роботи програми. Вид/Представлення (View) - це графічний інтерфейс, тобто вікно, кнопки і.т.п. Вид є передплатником на подію зміни значень властивостей або команд, що надаються Моделлю Представлення (ViewModel, що означає «Model of View»).

У разі, якщо в Моделі Представлення змінилося яка-небудь властивість, то вона сповіщає всіх передплатників про це, і Вид у свою чергу запитує оновлене значення властивості з Моделлю Представлення.

У випадку, якщо користувач впливає на який-небудь елемент інтерфейсу, Вид викликає відповідну команду, надану Моделлю Представлення.

Рис 1.4 Концепція Модель-Представлення-МодельПредставлення

Модель Представлення є з одного боку абстракцією Представлення, а з іншого надає обгортку даних з Моделі, які підлягають скріпленню. Тобто вона містить Модель, яка перетворена до Представленню, а також містить у собі команди, якими може користуватися представлення, щоб впливати на Модель [1, 3].

Надання студентам навичків використання ORM технології дасть їм можливість використовувати шаблони проектування при створены архітектури розроблювального програмного забезпечення які базуються на технології ORM .

Отже, використання ORM в проекті позбавляє розробника від необхідності роботи з SQL і написання великої кількості коду, часто одноманітного і схильного помилок.

Весь генерований ORM код добре перевірений і оптимізований, тому не потрібно в цілому замислюється про його тестуванні. Це безсумнівно є плюсом, але в теж час не варто забувати і про мінуси. Основний з них - це втрата продуктивності через те, що більшість ORM призначені для обробки широкого спектру сценаріїв використання даних, набагато більшого, ніж будь-яке окреме програмне забезпечення зможе використати.

На етапі виконання першого розділу було вирішено наступні задачі:

Виконано аналіз характеристик ORM, яка дозволяє перетворювати несумісні типи моделей в ООП-моделі, зокрема, між сховищем даних і об'єктами програмування;

Досліджено сутність проблеми парадигми «невідповідності», яку вирішує ORM;

Виконано аналіз існуючі архітектурні шаблони проектування, які полегшують і підвищують якість супроводу програмного забезпечення та за рахунок яких проводиться уніфікація термінології, назв модулів і елементів проекту.

Доведено доцільність розробки засобу візуалізації технології LINQ to SQL для його використання в навчальному процесі з метою надання студентам знань та навичок використання ORM-технологій при створенні архітектури розроблювального ПЗ

РОЗДІЛ 2. LINQ to SQL ЯК СУЧАСНА ORM ПЛАТФОРМА .NET FRAMEWORK

2.1 Основні характеристики LINQ to SQL

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

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

підтримувані мовою застосування, відрізняються від типів бази даних.

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

Наявність згаданих проблем об'єктно-реляційного відображення, часто званих об'єктно-реляційною втратою відповідності, протягом ряду років призвело до появи широкого розмаїття готових програмних ORM-рішень. LINQ to SQL - це реалізація ORM початкового рівня від Microsoft на основі LINQ, призначена для роботи з SQL Server.

LINQ це запит інтегрований в мову програмування який дозволяє писати безпечні структуровані запити до локальних колекціях об'єктів та віддалених джерел даних.

LINQ з'явився в NET Framework версии 3.5, який значно розширює можливості синтаксису мов C # і Visual Basic. LINQ надає стандартні, прості у вивченні шаблони для запиту і зміни даних і технології, які можуть бути розширені для підтримки практично будь-якого типу джерела даних. До складу Visual Studio входять збірки ресурсів LINQ, які зображені на рисунку 2.1, для використання LINQ з колекціями .NET Framework, базами даних SQL Server, наборами даних ADO.NET і XML-документами.

Рис. 2.1 Концепція технології LINQ

Спочатку підтримуючи механізм запитів для колекцій об'єктів в пам'яті, реляційних баз даних і даних у форматі XML, LINQ володіє розширюваною архітектурою, яка дозволяє стороннім розробникам реалізувати доступ до їх сховищ даних через механізм LINQ. Для цього необхідно реалізувати стандартні оператори запитів, використовуючи методи розширення, або реалізувати інтерфейс IQueryable, що дозволяє розбирати дерево вираження під час виконання, транслюючи його в свою мову запитів. У спільноті існує приклад користувальницької реалізації стандартних операторів запитів. Наприклад, LINQ to SQL, який перетворює LINQ-вирази в SQL-запити до бази даних, використовує можливості компілятора для побудови дерева виразів, грунтуючись на контексті програми, а не створюючи делегати функцій. Отримавши дерево виразів, що описує запит, спеціалізований провайдер бази даних може його проаналізувати і перетворити в запит на відповідній мові для бази даних, наприклад Microsoft SQL Server, Jet (яка використовується в Microsoft Access) або будь-який інший [6, 7].

Більшість інструментів ORM намагаються абстрагувати фізичну базу даних у вигляді бізнес-об'єктів. З такою абстракцією іноді втрачається можливість виконання запитів SQL, які становлять значну частину абстракції реляційних баз даних. Саме це відрізняє LINQ to SQL від більшості його аналогів. Ми не тільки отримуємо зручність у вигляді бізнес-об'єктів, які відображаються на базу даних, але також отримуємо повноцінну мову запитів, подібний SQL, приклад якої дуже добре зображено на рисунку 2.2.

Рис. 2.2 Концепція роботи LINQ to SQL

У LINQ to SQL модель даних реляційної бази даних зіставляється об'єктної моделі, вираженої в мові програмування розробника. При виконанні програми LINQ to SQL перетворює інтегровані в мову запити з об'єктної моделі в SQL і відправляє їх до бази даних для виконання. Коли база даних повертає результати, LINQ to SQL перетворює їх назад в об'єкти, з якими можна працювати на власній мові програмування.

Користувачі середовища Visual Studio, як правило, користуються конструктором Реляційний конструктор об'єктів, який надає користувальницький інтерфейс для реалізації багатьох функцій LINQ to SQL[7].

Загалом, LINQ to SQL - інструмент ORM початкового рівня, що дозволяє виконувати потужні SQL-запиту.

Технологію LINQ to SQL часто використовують в розробках програмного забезпечення. Під час навчання про цю технологію згадають поверхнево, та не розглядають основних принципів на яких базується ця технологія та механізмів її роботи. Доцільність розробки засобу візуалізації, полягає в надані студентам знань та навичок використання технології LINQ to SQL при створенні програмного забезпечення візуалізуючи процеси роботи технології LINQ to SQL.

Методика застосування LINQ to SQL при розробці програмного забезпечення засобами Visual Studio

LINQ to SQL - складна тема, і будь-які приклади вимагають участі багатьох елементів LINQ to SQL.

DataContext - це клас, який встановлює з'єднання з базою даних. Він також надає кілька служб, які зображені на рисунку 2.3, що забезпечують відстеження ідентичності, відстеження змін і обробку цих змін.

У LINQ to SQL прийнято використовувати клас, похідний від DataContext. Ім'я похідного класу зазвичай збігається з ім'ям бази даних, на яку він відображається. Нехай на цей похідний клас будемо посилатися як на [Your] DataContext, оскільки його ім'я залежить від бази даних, для якої він створений.

У наведених прикладах похідний від DataContext клас буде називатися Northwind. Для його побудови застосовувався інструмент SqlMetal, що входить до складу Visual Studio, який генерує класи відображення на основі бази даних SQL Server.

Рис. 2.3 Концепція функцій DataContext

Цей похідний від DataContext клас, [Your]DataContext, зазвичай буде мати загальнодоступне властивість Таblе <Т> для кожної таблиці бази даних, яка відображається на базу даних, де Т - тип сутнісного класу, екземпляр якого створюється для кожного витягнутого записису з конкретної таблиці бази даних.

Тип даних Table <T> являє собою спеціалізовану колекцію. Наприклад, оскільки в базі Northwind присутній таблиця Customers, клас Northwind, успадкований від класу DataContext, матиме Table <Customers> по імені Customers. Це означає, що звертатися до записів в таблиці Customers бази даних можна, безпосередньо звертаючись до властивості Customers типу Table <Customers> в класі Northwind [4, 5].

Квінтесенція LINQ to SQL полягає у відображенні сутнісних класів на таблиці бази даних і властивостей сутнісних класів на стовпці таблиць бази даних.

Таке відображення може виникати безпосередньо у вихідних файлах класу за рахунок оснащення їх відповідними атрибутами або ж може бути задане в зовнішньому XML-файлі відображення. При використанні такого зовнішнього файлу специфічна для LINQ to SQL інформація може зберігатися окремо від вихідного коду. Це може бути дуже зручно, якщо немає вихідного коду або якщо потрібно зберігати код окремо від LINQ to SQL.

У більшості прикладів, присвячених LINQ to SQL, використовуються сутнісні класи, згенеровані інструментом командного рядка SQLMetal. Цей інструмент генерує сутнісні класи з інформацією про відображення LINQ to SQL, вбудованої безпосередньо в генеруються вихідні модулі. Ця інформація представлена у формі атрибутів і їх властивостей.

Сутнісні класи мають ім'я у формі однини від імені таблиці бази даних Northwind. Наприклад, клас на ім'я Customer. Оскільки Customer-форма однини від Customers, а в базі даних Northwind є таблиця по імені Customers, це вказує на те, що Customer - сутнісний клас для таблиці Customers з бази даних.

Інструмент командного рядка SQLMetal підтримує опцію, яка викликає іменування сутнісного класу у формі однини імені таблиці бази даних. Якщо при генерації сутнісних класів ця опція не вказана, то клас отримав би ім'я Customers, а не Customer, бо такий ім'я таблиці - Customers. Сутнісний клас може мати ім'я як у множині, так і в однині.

Асоціація (association) - це термін, використовуваний для призначення первинного ключа для відносин зовнішнього ключа між двома сутнісними класами, які зображені на рисунку 2.4.

Рис. 2.4 Зв'язок між двома сутнісними класами

Відносно "один до багатьох" результатом асоціації є те, що батьківський клас - той, що містить первинний ключ - включає колекцію дочірніх класів, тобто класів, які мають зовнішній ключ. Ця колекція зберігається в приватній змінній типу EntitySet <T>, де Т буде типом дочірнього сутнісного класу.

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

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

Якщо конфлікт виявлений, генерується виключення ChangeConflictException. Кожен раз, коли ви викликаєте метод SubmitChanges, потрібно вміщувати його в блок try/catch і перехоплювати виключення ChangeConflictException. Це - правильний спосіб виявлення конфліктів паралельного доступу.

Як тільки конфлікт паралелізму виявлений, наступний крок полягає в його вирішенні. Це можна зробити декількома способами.

Наприклад, за рахунок виклику методу ResolveAll колекції ChangeConflicts успадкованого класу DataContext, коли перехоплено виняток ChangeConflictException.

Властивість Log об'єкта DataContext використовується для відображення трансльованого запиту SQL. Це може бути дуже корисно не тільки з метою налагодження, але і для аналізу продуктивності. Ви можете виявити, що запити LINQ to SQL транслюються в дуже неефективні запити SQL. Або ж з'ясувати, що через відкладене завантаження асоційованих сутнісних класів доводиться виконувати більше SQL-запитів, ніж необхідно. Властивість DataContext.Log забезпечить отримання такої інформації.

Метод GetChangeSet() об'єкта DataContext можна використовувати для отримання всіх сутнісних об'єктів, що містять зміни, які повинні бути збережені в базі даних при виклику SubmitChanges. Це зручно для протоколювання і налагодження.

Без сумнівів, однією з головних труднощів використання будь-якого інструменту ORM є управління змінами в базі даних. Якщо ви тримаєте всю логіку бізнес-класів і логіку LINQ to SQL в одних і тих же модулях, то цим створюєте собі проблеми супроводу при змінах бази даних.

Розгляньте можливість застосування часткових класів, поміщаючи бізнес-логіку в модуль, окремий від модулів згенерованих сутнісних класів. Використовуючи часткові класи для зберігання ваших атрибутів бази даних LINQ to SQL окремо від бізнес-логіки, ви мінімізуєте необхідність у додаванні коду до будь-якого згенеровані сутнісному класу.

В якості альтернативи можна розділити бізнес-класи та відображення сутностей LINQ to SQL за допомогою зовнішнього XML-файла відображення. Йдеться про XML-файли, який відображає бізнес-об'єкти на базу даних, не покладаючись на атрибути LINQ to SQL.

Часткові методи дозволяють втручатися в певні події, які відбуваються в сутнісних класах. Витонченість їх у тому, що якщо тіло часткового методу вирішено не реалізовувати, то при цьому не виникне жодних накладних витрат, і компілятор не буде генерувати код, пов'язаний з їх викликом.

Засоби опанування використання технології LINQ to SQL

У додатках часто використовуються дані з баз даних SQL або XML-документів. Зазвичай, розробники повинні були вивчати окрім основної мови програмування, такої як наприклад C#, так і додаткову як SQL. LINQ (Language-Integrated Query) надає можливість здійснювати запити на самій мові C#. Тепер, замість вивчення окремої мови запитів, можна виконувати запити до баз даних SQL, наборам даних ADO.NET, XML-документами і будь-яким класам колекцій. NET Framework, що реалізують інтерфейс IEnumerable, використовуючи знання C# і декількох додаткових ключових слів і основних понять.

Використовуйте LINQ to SQL для доступу до баз даних SQL Server і SQL Server Express через строго типізований об'єктний шар, який створюється за допомогою об'єктно-реляційного конструктору. Його можна використовувати для порівняння класів LINQ to SQL таблиць в базі даних і потім створювати запити LINQ для прив'язки даних до елементів управління у додатку.

Об'єктно-реляційний конструктор надає візуальну область конструктора для створення класів сутностей і асоціацій (відносин) LINQ to SQL, які базуються на об'єктах в базі даних. Іншими словами, Об'єктно-реляційний конструктор використовується для створення моделі об'єкта в додатку, яка співставляється з об'єктами в базі даних. Модель також генерує DataContext із суворим контролем введення, який використовується для відправки та отримання даних між класами сутностей і базою даних. Об'єктно-реляційний конструктор генерує DBML-файл, який забезпечує співставляється між класами LINQ to SQL та об'єктами бази даних. Реляційний конструктор об'єктів також генерує DataContext і класи сутностей.

Після додавання елемента LINQ to SQL Classes в проект і відкриття об'єктно-реляційного конструктору, порожня область конструктора представляє порожній DataContext, готовий до конфігурації. DataContext конфігурується з інформацією про підключення, наданої першим елементом, який був перетягнути в область конструктора. Тому DataContext конфігурується з використанням інформації про підключення з першого переміщеного в область конструктора елемента.

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

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

Можна створювати методи DataContext, які викликають збережені процедури і функції. Крім того, можна також призначати збережені процедури, які можуть використовуватися для поведінки за замовчуванням при LINQ to SQL середовища виконання, яка виконує Вставки, Оновлення та видалення.

Подібно іншим об'єктам, LINQ to SQL класи можуть використовувати спадкування і виводитися з інших класів. Об'єктно-реляційний конструктор забезпечує властивості контекстного простору імен і Простору імен сутностей на DataContext. Ці властивості визначають, який простір імен DataContext та коду класів сутностей генерується в ньому. За замовчуванням ці властивості порожні і DataContext класи сутностей генеруються в просторі імен додатки. Щоб згенерувати код у простір імен, відмінне від простору імен додатки, введіть значення в властивості Контекстне простір імен та/або простір імен сутностей [6, 7].

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

LINQ to SQL - інструмент ORM початкового рівня, що дозволяє виконувати потужні SQL-запити. LINQ to SQL має засоби відстеження змін і оновлень бази даних, побудованих на основі оптимістичній моделі виявлення і вирішення конфліктів паралельного доступу, а також транзакційної цілісності.

В ході аналізу предметної області було вирішено наступні задачі:

1) Проведено аналіз основних характеристик технології LINQ to SQL, яка призначена для роботи з базами даних SQL Server;

2) Досліджено методики застосування LINQ to SQL при розробці програмного забезпечення засобами Visual Studio;

3) Виконано аналіз існуючих засобів опанування технології LINQ to SQL.

4) Доведено доцільність розробки засобу візуалізації технології LINQ to SQL для його використання в навчальному процесі з метою надання студентам знань та навичок використання технології LINQ to SQL в розробці ПЗ



РОЗДІЛ 3. РОЗРОБКА ЗАСОБУ ВІЗУАЛІЗАЦІЇ LINQ to SQL

3.1 Вимоги до засобу візуалізації LINQ to SQL

UML (Unified Modeling Language - уніфікована мова моделювання) є мовою графічного опису для об'єктного моделювання при розробці програмного забезпечення. Мова UML був розроблений як уніфікація безлічі нотацій, які використовувалися для графічного опису об'єктно-орієнтованих систем. UML описує системи за допомогою набору діаграм. Кожна така діаграма є поглядом «зі свого боку» на систему.

Діаграма прецедентів (Use case diagram) - представляє різні сутності, які взаємодіють з системою (користувачів, зовнішні пристрої та інші програмні системи) і вказують функції, які необхідно реалізувати в програмній системі.

Актор (actor) ініціює прецедент (use case). Прецедент описує послідовність взаємодій між актором і системою. Актор зображується на діаграмі у вигляді фігури чоловічка, система - у вигляді прямокутника, прецедент - у вигляді еліпса всередині цього прямокутника.

Діаграма прецедентів служить для опису групи дій, які ініціюються конкретною особою. Таким чином її основне призначення - спрощення взаємодії з користувачами. Діаграма прецедентів описує, що система повинна робити і як це буде виглядати для користувача.

Актори являють собою не фізичних людей, а їх ролі. Це означає, що коли людина взаємодіє з системою різними способами (припускаючи різні ролі), він відображається декількома акторами. У поняття актор входять люди, комп'ютерні системи і процеси.

До прецедентів в UML застосований такий вид відносин як асоціація (Association), що може вказувати на те, що актор ініціює відповідний варіант використання.

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

Розширення (Extend) - являється різновидом відносин залежності між базовим варіантом використання та його спеціальним випадком.

Включення (Include) - визначає взаємозв'язок базового варіанту використання з іншим варіантом використання, функціональне поведінка якого завжди задіюється базовим варіантом використання.

Узагальнення (Generalization) - моделює відповідну спільність ролей.

При проектуванні програмної системи проводиться пошук таких класів для реалізації прецеденту, які вдало поєднували б у собі необхідні ролі і не призводять до зайвого ускладнення системи. Реалізацію прецеденту можна змоделювати у вигляді однієї або декількох кооперацій (реалізацій прецеденту). Один і той же прецедент може бути описаний з різним ступенем деталізації[7].

Діаграма прецедентів засобу візуалізації технології LINQ to SQL зображена в додатку А.

Діаграма послідовності (Sequence diagram) - Діаграма послідовності є однією з діаграм взаємодій і відображає послідовність виконання програми в термінах взаємодії об'єктів.

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

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

Горизонтальні стрілки показують передачу управління (посилка повідомлення, виклик методу).

Діаграма послідовності засобу візуалізації технології LINQ to SQL зображена в додатку Б.

Загальна архітектура засобу візуалізації LINQ to SQL

Архітектура програмного забезпечення - це структура програми або обчислювальної системи, яка включає програмні компоненти, видимі зовні властивості цих компонентів, а також відносини між ними. Цей термін стосується також до документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими особами, дозволяє зафіксувати прийняті на ранніх етапах проектування рішення про високорівневої дизайні системи і дозволяє використовувати компоненти цього дизайну і шаблони повторно в інших проектах[4].

Архітектура засобу візуалізації LINQ to SQL відображена на рис. 3.1. Вона включає в себе три компоненти: програмну частину, ORM та базу даних.

Рис 3.1 Загальна архітектура засобу візуалізації LINQ to SQL

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

ORM пов'язує базу даних з програмною частиною перетворюючи запити LINQ з об'єктної моделі в SQL і відправляє їх до бази даних для виконання.

БД представлена базою DataBase, що знаходиться на локальному сервері Microsoft SQL Server Express (64-bit) версії 11.0.2218.0.

Розробка складових засобів візуалізації

Для реалізації засобу моніторингу використовувалась мова C#, засоби WPF та Linq.

Windows Presentation Foundation(WPF) - система для побудови клієнтських додатків Windows з візуально привабливими можливостями взаємодії з користувачем, графічна (презентаційна) підсистема у складі. NET Framework (починаючи з версії 3.0), що використовує мову XAML.

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

Графічної технологією, що лежить в основі WPF, є DirectX, на відміну від Windows Forms, де використовується GDI/GDI+.

Language Integrated Query (LINQ) - проект Microsoft по додаванню синтаксису мови запитів, що нагадує SQL, в мови програмування платформи. NET Framework. Являє собою не що інше, як функціональне програмування, замасковане під синтаксис SQL. LINQ це запит інтегрований в мову програмування який дозволяє писати безпечні структуровані запити до локальних колекціях об'єктів та віддалених джерел даних.

При створенні робочої області програми було вирішено створити три вікна в кожному з яких буде демонструватися окремий пункт ознайомлення з технологією LINQ to SQL.

В першому вікні демонструється особливість мови SQL. Перше вікно зображено в додатку В.

Воно містить діаграму зв'язків між таблицями бази даних в якій кожну окрему таблицю можна розгортати чи згортати під час чого буде демонструватися SQL-код в правій частині вікна. Для демонстрації SQL-запитів користувач може вибрати декілька готових варіантів запиту результат яких буде відображатися в елементі управління DataGrid. Для детальнішого вивчення SQL-запитів користувач може скористатися кнопкою “help” після натиснення якої буде відкрите вікно, яке зображено на рис 3.3, з розгорнутою інформацією про мову SQL.

В другому вікні демонструється перетворення запитів LINQ з об'єктної моделі в SQL. Друге вікно зображено в додатку Г. Воно містить діаграму зв'язків між таблицями бази даних в якій кожну окрему таблицю можна розгортати чи згортати під час чого буде демонструватися як перетворюється запит LINQ з з об'єктної моделі в SQL. Для більше детальнішого вивчення цього процесу користувач може скористатися кнопкою “help” після натиснення якої буде відкрите вікно, з розгорнутою інформацією.

Рис. 3.3 Вікно SQL “help”

В третьому вікні демонструються можливості технології LINQ to SQL. Третє вікно зображено в додатку Д. Воно надає можливість користувачу обирати з декількох готових варіантів LINQ-запити, результат яких буде демонструватися в елементів управління DataGrid.

На основі вибраного варіанту LINQ-запиту, користувач може вносити зміни в інформацію, чи видаляти ії по заданим критеріям. Для детальнішого вивчення технології LINQ to SQL користувач може скористатися кнопкою “help” після натиснення якої буде відкрите вікно з розгорнутою інформацією про технологію LINQ to SQL.

В програмній частині реалізовано 3 класи: phase1_SQL, phase2_LINQ_to_SQL, phase3_Application. Також було автоматично створено класи для роботи с базою даних: Employees, Product, Customers, Categories, Suppliers. Діаграма класів представлена в додатку Е.

Клас phase1_SQL відповідає за роботу з вікном в якому демонструються SQL-запити та за відображення схеми таблиць бази даних. Опис компонентів представлений в таблиці 3.1.

Клас phase2_LINQ_to_SQL відповідає за демонстрацію перетворення запитів LINQ з об'єктної моделі в SQL. Опис компонентів представлений в таблиці 3.2.

Клас phase3_Application відповідає за демонстрацію технології LINQ to SQL. Опис компонентів представлений в таблиці 3.3.

Таблиця 3.2

Опис компонентів класу phase1_SQL

Компонент	Опис
Help	Метод, що відповідає за переход на сторінку “help”
LinqToSqlNav	Метод, завдяки якому відбувається перехід з вікна phases1_SQL до вікна phases2_LINQ_to_SQL.
ApplicationNav	Метод, завдяки якому відбувається перехід з вікна phases1_SQL до вікна phases3_Application.
SetDataGrid	Метод що викликається для заповнення елемента управління DataGrid
Schema_changes	Метод, що відображає SQL-код обраної користувачем таблиці

Таблиця 3.4

Опис компонентів класу phase2_LINQ_to_SQL

Компонент	Опис
SQLNav	Метод, завдяки якому відбувається перехід з вікна phases2_LINQtoSQL до вікна phases1_SQL.
ApplicationNav	Метод, завдяки якому відбувається перехід з вікна phases2_LINQtoSQL до вікна phases3_Application.
Schema_changes	Метод, що реалізує жемонстрацію перетворення запитів LINQ з об'єктної моделі в SQL
ManipulateLinq	Метод, що демонструэ перетворення запросів с SQL в LINQ
Help	Метод, що відповідає за переход на сторінку “help”

Таблиця 3.5

Опис компонентів класу phase3_Application

Компонент	Опис
SetDataGrid	Метод що викликається для заповнення елемента управління DataGrid
UpdateDataGrid	Метод, що відповідає за оновлення БД зміни інформації
DeleteDataGrid	Метод, що відповідає за видалення з БД інформації
InsertDataGrid	Метод, що відповідає за додавання в БД інформації
Help	Метод, що відповідає за переход на сторінку “help”
LinqToSqlNav	Метод, завдяки якому відбувається перехід з вікна phases3_Application до вікна phases2_LINQtoSQL.
SQLNav	Метод, завдяки якому відбувається перехід з вікна phases3_Application до вікна phases1_SQL.

Отже, розроблений засіб візуалізації досить глибоко показує особливості LINQ to SQL, та демонструє можливості та переваги ОРМ технології.

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

Засіб візуалізації демонструє різницю між технологією інтегрованою в мову програмування LINQ та мовою SQL. Користувачі які вже знали мову SQL порівнюючи з технологією LINQ to SQL зможуть швидше її засвоїти, та навпаки.

Для більше детального вивчення цієї технології надається можливість до додаткового матеріалу в кожному пункті програми.

На етапі виконання розробки засобу візуалізації LINQ to SQL було вирішено наступні задачі::

1) Проведено аналіз основних вимог до засобу візуалізації технології LINQ to SQL;

2) Розроблено загальну архітектуру засобу візуалізації LINQ to SQL;

3) Було розроблено складові засобу візуалізації технології LINQ to SQL.

3) Було розроблено методику використання засобу візуалізації технології LINQ to SQL.



ВИСНОВКИ

В процесі роботи з предметною областю пов'язаною з розробкою засобу візуалізації технології LINQ to SQL було досліджено, що в сучасному навчанні не завжди детально демонструються принципи роботи сучасних технологій і це негативно впливає на якість засвоєння матеріалу, що веде до погіршення рівня освіти.

Для вирішення цієї проблеми було розроблено засіб візуалізації технології LINQ to SQL, яка демонструє можливості та засоби використання технології LINQ.

В ході дослідження проблеми було проведено аналіз характеристик ORM, досліджено сутність проблеми парадигми «невідповідності», проведено аналіз основних характеристик технології LINQ to SQL, виконано аналіз існуючих засобів опанування технології LINQ to SQL.

Дане ПЗ демонструє різницю між технологією інтегрованою в мову програмування LINQ та мовою SQL. Користувачі які вже знали мову SQL порівнюючи з технологією LINQ to SQL зможуть швидше її засвоїти і навпаки. Для детальнішого вивчення цієї технології є можливість користуватися додатковою інформацією яка вбудована в ПЗ.

Розробка засобу візуалізації технології LINQ to SQL покращує засвоєння розглянутого навчального матеріалу, що веде до покращення якості освіти, але це ПЗ навчає лише однієї технології, для повного вирішення навчальної проблеми, потрібно розробляти більше подібного ПЗ, для суттєвого покращення якості навчального процесу.

Таким чином під час написання дипломного проекту було створено програмний засіб візуалізації технології LINQ to SQL, що відповідає наступним вимогам: простота засвоєння навчального матеріалу по даній темі, демонстрація можливостей технології LINQ to SQL, додаткова інформація для детального вивчення матеріалу, демонстрація перетворення запитів LINQ з об'єктної моделі в SQL.

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

Паттерни проектування. - Корпорация Microsoft, 2011. - 46 с. [Электронный ресурс] - Режим доступа: http://outcoldman.com/ru/blog/show/184

Vijay Perelman Pro LINQ Object Relational Mapping with C#: Thomson learning, 2008 -27 с.

Barry Blundell Computer hardware London : Thomson, 2008.

D.A.Godse A.P.Godse Computer Organization And Architecture Pune, India : Technical Publications, 2010.

William Stallings Computer Organization & Architecture 7e

Шилдт Г. - C# 4.0 полное руководство. 9-е изд., 2013 год - 748 с.

Эндрю Троелсен - Язык программирования C# 5.0 и платформа .NET 4.5 6-е издание Издательство: Вильямс, 2013 -537 с.

Положення про дипломні роботи (проекти) випускників Національного авіаційного університету К. : НАУ, 2011 - 50 с.

Размещено на Allbest.ru