іклікає методи моделі, и встановлює дані з моделі під 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 Концепція Модель-Представлення-МодельПредставлення
Модель Представлення є з одного боці абстракцією Представлення, а з Іншого надає обгортку даних з моделі, Які підлягають скріпленню. Тобто вона містіть Модель, яка превратилась до подання, а такоже містіть у Собі команда, Якими может користуватись представлення, щоб впліваті на Модель [1, 3].
Надання студентам навічків использование ORM технології дасть Їм можлівість використовуват Шаблони проектування при створі архітектури розроблювальних програмного забезпечення Які базуються на технології ORM.
Отже, использование ORM в проекті позбавляє розробника від необхідності роботи з SQL и написання Великої кількості коду, часто одноманітного и схільного помилок.
Весь генерованій ORM код добро перевіреній и оптімізованій, тому не нужно в цілому заміслюється про его тестуванні. Це безсумнівно є плюсом, но в теж годину не Варто забуваті и про мінуси. Основна з них - це Втрата продуктівності через том, что більшість ORM прізначені для ОБРОБКИ широкого спектру сценаріїв использование даних, набагато БІЛЬШОГО, чем будь-яке окреме програмне забезпечення зможите вікорістаті.
На етапі виконан Першого розділу Було вірішено следующие задачі:
виконан аналіз характеристик ORM, яка дозволяє перетворюваті несумісні тіпі моделей в ООП-моделі, зокрема, между Сховище даних и об'єктами программирования;
Досліджено Сутність проблеми парадигми «невідповідності», якові вірішує ORM;
виконан аналіз існуючі архітектурні Шаблони проектування, Які полегшують и підвіщують якість супроводу програмного забезпечення та за рахунок якіх проводитися уніфікація термінології, назв модулів и елементів проекту.
Доведено доцільність розробки Засоби візуалізації технології LINQ to SQL для его использование в навчальному процессе з метою Надання студентам знань та навічок использование ORM-технологій при створенні архітектури розроблювальних ПЗ
РОЗДІЛ 2. LINQ to SQL ЯК СУЧАСНА ORM ПЛАТФОРМА .NET FRAMEWORK
.1 Основні характеристики LINQ to SQL
У сучасности мире, де панують про єктно-орієнтовані мови програмування, існує невідповідність между мовою програмування и реляційною базою даних. При написанні програми ми моделюємо класи як уявлення про єктів реального світу. Нам потрібен способ Збереження ціх про єктів, щоб при перезапуску програми всі ЦІ про єкти з їх Даними НЕ були Втрачені.
Однако більшість баз даних промислового масштабом залішаються реляційнімі и зберігають свою інформацію у виде запісів в таблицях, а не у виде об'єктів. Корістувальніцькій клас может містіті кілька адреса и номерів телефонов, что зберігаються в колекціях, Які є дочірнімі властівостямі класу замовника, при збереженні така інформація, швидше за все, розподіліться по Багат таблиці, например, в таблицю замовніків, таблиці адрес и таблицю телефонов. Типи даних,
підтрімувані мовою! застосування, відрізняються від тіпів бази даних.
розробник доводитися писати власний код, Який завантажує и зберігає об'єкти замовніків з відповідніх таблиці, обробляючі необхідні превращение даних между мовою Додатків и базою даних. Це віснажлівій, и часто схільній до помилок процес.
На...
