єктно-реляційні відображення могут існуваті в різноманітніх формах, з Якими найпростіше розуміються засоби автоматичного про єктно-реляційного відображення. У самій розгорнутій форме засіб автоматичного про єктно-реляційного відображення зберігає в базі даних НЕ только стан прикладних про єктів, но и метадані.
Засіб об'єктно-реляційного відображення такого уровня представляет собою спеціалізовану ООСУБД, мова Запитів якої максимально набліженій до ЗАСОБІВ доступу до даних базової мови програмування, а відповідна SQL-орієнтована база даних вікорістовується только як середовище зберігання.
Найбільш масштабним проектом, пов язань Із ЗАБЕЗПЕЧЕННЯМ розшірювальніх можливіть про єктно-реляційного відображення для цілого ряду мов програмування, є LINQ Компанії Microsoft. Перші реализации були віконані для мов C # и Visual Basic.NET [2].
Вирішення проблеми ORM
Суть проблеми, яка вірішується помощью ORM, Полягає в необхідності превращение про єктніх структур в пам яті програми у форму, зручне для Збереження в реляційніх базах даних, а такоже для вирішенню зворотнього Завдання - розгортання реляційної моделі в об єктну , зі збереженням властівостей про єктів и отношений между німі.вірішує проблему так званої парадигми «невідповідності», яка говорити про том, что про єктні та реляційні моделі НЕ Дуже добре Працюють разом. Реляційні бази представляються дані в табличному форматі, в тій годину як про єктно-орієнтовані мови представляються їх як зв язаний граф про єктів. Основна проблема и невідповідность вінікає во время Збереження цього графа об'єктів у реляційну базу або его завантаження:
реляційна модель может буті набагато детальніше, чем об'єктна;
реляційні СУБД НЕ мают Нічого Спільного з Успадкування - природну парадигму об'єктно-орієнтованих мов програмування;
в СУБД визначеня только один параметр для порівняння запісів - первинний ключ;
для зв язку про єктів СУБД вікорістовує Поняття зовнішнього ключа, в об єктно-орієнтованих мовах зв язок между об'єктами может буті только односпрямованій. Если ж нужно організуваті двонаправлені звязки, то придется візначіті две односпрямовані асоціації;
для доступу до даних в ООП Використовують послідовні переходь від батьківського про єкта до властівостей дочірніх елементів и ініціалізації про єктів за необхідністю. Такий ПІДХІД вважається ефективна способом Отримання даних з реляційніх баз даних [2, 3].
Використання ORM в проекті позбавляє розробника в необхідності роботи з SQL и написання Великої кількості коду, часто одноманітного и з великою кількістю помилок. Весь генерованій ORM код добро перевіреній и оптімізованій, тому не нужно в цілому заміслюється про его тестування. Це безсумнівно є плюсом, но в тей же годину не Варто забуваті и про мінуси. Основна з них - це Втрата продуктівності. Це відбувається тому, что більшість ORM прізначені для ОБРОБКИ широкого спектру сценаріїв использование даних, набагато БІЛЬШОГО, чем будь-яке окреме! Застосування зможите використовуват.
Питання про доцільність использование ORM за великим Рахунка чіпляється только у великих проектах, Які зустрічаються з високим навантаженості, тут доводитися обирати что являється більш пріорітетнім - зручність чи Продуктивність. Робота з БД помощью грамотно написаного SQL-коду буде набагато ефектівніше, альо НЕ Варто забуваті и про такий параметр, як годину - том, что з легкістю пишеться з використанн ORM за тиждень, можна реалізовуваті не один місяць ВЛАСНА зусилля. Крім того, більшість СУЧАСНИХ ORM дозволяють програмісту при необхідності самому задаваті код SQL-Запитів. Для невеликих проектів использование ORM буде куди більш віправдованішім, чем розробка ВЛАСНА бібліотек для роботи з БД.
Крім того, поряд з проблемою.Більше розробки Додатків є НЕ Менш Важлива проблема їх супроводу. Як правило, супроводиться Додатків займаються НЕ розробник Додатків, а зовсім Інші люди. Цім фахівцям набагато простіше мати дело з одноріднімі текстами програм, Повністю написанні на одній мові програмування.
Технологія ОRМ має очень Широке использование в сучасности ІТ мире. Зазвічай во время навчання про Цю технологію згадають поверхнево, або зовсім НЕ згадують. Доцільність розробки Засоби візуалізації, Полягає в надані студентам знань та навічок использование технології ОRМ при створенні архітектури розроблювальних програмного забезпечення.
Шаблони багатошарової архітектури
Шаблон проектування НЕ являється закінченім зразки, Який можна превратить прямо в код. Це лишь приклад розвязання поставленої задачі, Який можна застосуваті в різніх сітуаціях. Об'єктно-орієнтовані Шаблони демонструють як взаємодіють между собою класи та обєкти, без визначення того, Які кінцеві класи чі обєкти! Застосування будут використовуват.
«Нізькорівневі» шаблони, что враховують спеціфіку конкретної мови програмування, назіваються ідіомамі. Це г...
