Дипломная (вкр): Засіб візуалізації технології LINQ to SQL

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

РЕФЕРАТ

Пояснювальна записка до дипломного проекту «Засіб візуалізації технології LINQ to SQL»: 39 с., 13 рис., 3 табл., 7 інформаційних джерел, 3 додатка., LINQ to SQL, БАГАТОШАРОВІСТЬ, SQL, LINQ, .NET, MVC, MVC, MVP, MVVM

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

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

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

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

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

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

ООП - Об'єктно-орієнтоване програмування.- Об'єктно-реляційне відображення (Object-relational mapping)

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

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

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

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

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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