В тази статия ще се запознаем с нещо, наречено MVC. Ще говорим Howво е MVC, ще се докоснем до неговата история, ще проучим основните идеи и концепции, въплътени в MVC, ще разгледаме стъпка по стъпка How да разделим приложение на модули Model, View и Controller, ще напишем малко уеб приложение, използващо Spring Boot, и като използвате Spring MVC като пример, вижте How данните се изпращат от Java code към HTML страници. За да разберете този материал, трябва да сте запознати с дизайнерските модели, особено наблюдателя и фасадата. И да сте запознати с HTTP заявките и отговорите, да разбирате основите на HTML и да знаете Howво представляват анотациите на Java. Вземете чаша кафе и лека закуска и се настанете удобно. Нека да започнем.
История на MVC
Идеите зад MVC са формулирани от Trygve Reenskaug, докато работи в Xerox PARC в края на 70-те години. В онези дни работата с компютри изискваше диплома и постоянно изучаване на обемна documentация. Задачата, решена от Reenskaug заедно с група много силни разработчици, беше да се опрости взаимодействието на обикновен потребител с компютъра. Беше необходимо да се създадат инструменти, които, от една страна, да бъдат изключително прости и разбираеми, а от друга страна, да направят възможно управлението на компютри и сложни applications. Reenskaug работи в екип, който разработи преносим компютър „за деца от всички възрасти“ — Dynabook, Howто и езика SmallTalk под ръководството на Алън Кей. Тогава бяха положени концепциите за приятелски интерфейс. В много отношения, работата, извършена от Reenskaug и неговия екип, повлия на развитието на ИТ сферата. Ето един интересен факт, който не се отнася директно за MVC, но илюстрира meaningто на тези разработки. Алън Кейказах, „Когато за първи път стигнах до Apple, което беше през 1984 г., Mac вече беше пуснат и Newsweek се свърза с мен и ме попита Howво мисля за Mac. Казах, „Е, Mac е първият персонален компютър, достатъчно добър за бъда критикуван.' И така, след като обяви iPhone през 2007 г., той ми го донесе и ми го даде. Той каза: "Алън, това достатъчно добро ли е, за да бъде критикувано?" И аз казах: „Стив, направи го толкова голям, колкото таблет и ще управляваш света.“ След 3 години, на 27 януари 2010 г., Apple представи iPad с диагонал от 9,7 инча. С други думи, Стив Джобс следва почти точно съвета на Алън Кей. Проектът на Reenskaug продължи 10 години. Но първата публикация за MVC се появи на бял свят след още 10 години. Мартин Фаулър, автор на няколко книги и статии за софтуерната архитектура, споменава, че е изучавал MVC, използвайки работеща version на Smalltalk. Тъй като дълго време нямаше информация за MVC от оригиналния източник и поради няколко други причини се появиха голям брой различни интерпретации на тази концепция. В резултат на това мнозина смятат MVC за модел на проектиране. По-рядко MVC се нарича съставен шаблон or комбинация от няколко шаблона, които работят заедно за създаване на сложни applications. Но, Howто споменахме по-рано, MVC всъщност е преди всичко набор от архитектурни идеи/принципи/подходи, които могат да бъдат реализирани по различни начини, използвайки различни модели... След това ще разгледаме основните идеи, вградени в концепцията на MVC. и поради няколко други причини се появиха голям брой различни интерпретации на това понятие. В резултат на това мнозина смятат MVC за модел на проектиране. По-рядко MVC се нарича съставен шаблон or комбинация от няколко шаблона, които работят заедно за създаване на сложни applications. Но, Howто споменахме по-рано, MVC всъщност е преди всичко набор от архитектурни идеи/принципи/подходи, които могат да бъдат реализирани по различни начини, използвайки различни модели... След това ще разгледаме основните идеи, вградени в концепцията на MVC. и поради няколко други причини се появиха голям брой различни интерпретации на това понятие. В резултат на това мнозина смятат MVC за модел на проектиране. По-рядко MVC се нарича съставен шаблон or комбинация от няколко шаблона, които работят заедно за създаване на сложни applications. Но, Howто споменахме по-рано, MVC всъщност е преди всичко набор от архитектурни идеи/принципи/подходи, които могат да бъдат реализирани по различни начини, използвайки различни модели... След това ще разгледаме основните идеи, вградени в концепцията на MVC.
MVC: Основни идеи и принципи
VC е набор от архитектурни идеи и принципи за изграждане на сложни информационни системи с потребителски интерфейс
MVC е съкращение, което означава: Model-View-Controller
Отказ от отговорност: MVC не е шаблон за проектиране. MVC е набор от архитектурни идеи и принципи за изграждане на сложни системи с потребителски интерфейс. Но за удобство, за да не казваме многократно "набор от архитектурни идеи...", ще се позоваваме на шаблона MVC. Нека започнем с простото. Какво се крие зад думите Model-View-Controller? Когато използвате модела MVC за разработване на системи с потребителски интерфейс, трябва да разделите системата на три компонента. Те също могат да бъдат наречени модули or компоненти. Наречете ги Howто искате, но разделете системата на три компонента. Всеки компонент има свое преднаmeaning. Модел. Първият компонент/модул се нарича модел. Той съдържа цялата бизнес логика на приложението. Преглед.Втората част от системата е изгледът. Този модул отговаря за показването на данни на потребителя. Всичко, което потребителят вижда, се генерира от изгледа. Контролер.Третата връзка в тази верига е контролерът. Той съдържа codeа, който отговаря за обработката на потребителските действия (всички потребителски действия се обработват в контролера). Моделът е най-независимата част от системата. Толкова независим, че не трябва да знае нищо за модулите за изглед и контролер. Моделът е толкова независим, че разработчиците му може да не знаят почти нищо за изгледа и контролера. Основната цел на изгледа е да предостави информация от модела във формат, който потребителят може да използва. Основното ограничение на изгледа е, че не трябва да променя модела по ниHowъв начин. Основната цел на контролера е да управлява действията на потребителя. Чрез контролера потребителят прави промени в модела. Или по-точно към данните, които се съхраняват в модела. Ето диаграмата, която видяхте преди в урока: От всичко това можем да направим логичен извод. Една сложна система трябва да бъде разделена на модули. Нека опишем накратко стъпките за постигане на това разделяне.
Стъпка 1. Отделете бизнес логиката на приложението от потребителския интерфейс
Основната идея на MVC е, че всяко приложение с потребителски интерфейс може да бъде разделено на 2 модула: модул, отговорен за внедряването на бизнес логиката, и потребителски интерфейс. Първият модул ще реализира основната функционалност на приложението. Този модул е ядрото на системата, където е реализиран домейн моделът на приложението. В MVC парадигмата този модул е буквата М, тоест моделът. Вторият модул реализира целия потребителски интерфейс, включително логиката за показване на данни на потребителя и управление на взаимодействието на потребителя с приложението. Основната цел на това разделяне е да се гарантира, че ядрото на системата („моделът“ в терминологията на MVC) може да бъде независимо разработено и тествано. След като направите това разделяне, архитектурата на приложението изглежда така:
Стъпка 2 Използвайте модела на наблюдателя, за да направите модела още по-независим и да синхронизирате потребителските интерфейси
Тук имаме 2 цели:
Постигнете още по-голяма независимост на модела
Синхронизирайте потребителските интерфейси
Следващият пример ще ви помогне да разберете Howво имаме предвид под синхронизиране на потребителски интерфейси. Да предположим, че купуваме билет за кино онлайн и виждаме броя на свободните места в киносалона. В същото време някой друг може да купува билет за кино. Ако този друг човек купи билет преди нас, бихме искали да видим намаляване на броя на свободните места за часа на шоуто, който обмисляме. Сега нека помислим How това може да се приложи в рамките на програма. Да предположим, че имаме ядрото на нашата система (нашият модел) и интерфейс (уеб pageта за закупуване на билети). Двама потребители се опитват да изберат място в театъра едновременно. Първият потребител купува билет. Уеб pageта трябва да покаже на втория потребител, че това се е случило. Как трябва да стане това? Ако актуализираме интерфейса от ядрото, тогава ядрото (нашият модел) ще зависи от интерфейса. Докато разработваме и тестваме модела, ще трябва да имаме предвид различните начини за актуализиране на интерфейса. За да постигнем това, трябва да приложим модела на наблюдателя. Този модел позволява на модела да изпраща известия за промяна до всички слушатели. Като слушател на събития (or наблюдател), потребителският интерфейс получава известия и се актуализира. От една страна, моделът на наблюдателя позволява на модела да информира интерфейса (изглед и контролер), че са настъпor промени, без всъщност да знае нищо за това, като по този начин остава независим. От друга страна, той прави възможно синхронизирането на потребителските интерфейси. трябва да приложим модела на наблюдателя. Този модел позволява на модела да изпраща известия за промяна до всички слушатели. Като слушател на събития (or наблюдател), потребителският интерфейс получава известия и се актуализира. От една страна, моделът на наблюдателя позволява на модела да информира интерфейса (изглед и контролер), че са настъпor промени, без всъщност да знае нищо за това, като по този начин остава независим. От друга страна, той прави възможно синхронизирането на потребителските интерфейси. трябва да приложим модела на наблюдателя. Този модел позволява на модела да изпраща известия за промяна до всички слушатели. Като слушател на събития (or наблюдател), потребителският интерфейс получава известия и се актуализира. От една страна, моделът на наблюдателя позволява на модела да информира интерфейса (изглед и контролер), че са настъпor промени, без всъщност да знае нищо за това, като по този начин остава независим. От друга страна, той прави възможно синхронизирането на потребителските интерфейси.
Стъпка 3 Разделете интерфейса на изглед и контролер
Продължаваме да разделяме приложението на модули, но вече на по-ниско ниво в йерархията. На тази стъпка потребителският интерфейс (който отделихме в отделен модул в стъпка 1) се разделя на изглед и контролер. Начертаването на строга граница между изгледа и контролера е трудно. Ако кажем, че изгледът е това, което потребителят вижда, а контролерът е механизмът, който позволява на потребителя да взаимодейства със системата, може да посочите противоречие. Контролните елементи, като бутони на уеб page or виртуална клавиатура на екрана на телефона, са основно част от контролера. Но те са толкова видими за потребителя, колкото всяка част от изгледа. Това, за което наистина говорим тук, е функционално разделяне. Основната задача на потребителския интерфейс е да улесни взаимодействието на потребителя със системата.
извежда и показва удобно системна информация на потребителя
въведете потребителски данни и команди (съобщете ги на системата)
Тези функции определят How потребителският интерфейс трябва да бъде разделен на модули. В крайна сметка архитектурата на системата изглежда така: Ето How стигаме до приложение, състоящо се от три модула, наречени модел, изглед и контролер. Нека обобщим:
Съгласно принципите на MVC парадигмата, системата трябва да бъде разделена на модули.
Най-важният и независим модул трябва да бъде моделът.
Моделът е ядрото на системата. Трябва да е възможно да се разработи и тества независимо от потребителския интерфейс.
За да постигнем това, в първата стъпка на разделянето трябва да разделим системата на модел и потребителски интерфейс.
След това, използвайки модела на наблюдател, ние укрепваме независимостта на модела и синхронизираме потребителските интерфейси.
Третата стъпка е да разделите потребителския интерфейс на контролер и изглед.
Всичко, което е необходимо за получаване на потребителски данни в системата, е в контролера.
Всичко, което е необходимо за предоставяне на информация на потребителя, е в изгледа.
Само още едно важно нещо, което трябва да обсъдите, преди да можете да изпиете своя горещ шоколад.
Малко за това How изгледът и контролерът взаимодействат с модела
Чрез въвеждане на информация през контролера, потребителят променя модела. Или поне потребителят променя данните на модела. Когато потребителят получава информация чрез интерфейсни елементи (чрез изгледа), потребителят получава информация за модела. How става това По Howъв начин изгледът и контролерът взаимодействат с модела? В крайна сметка класовете на изгледа не могат директно да извикват методите на класовете на модела за четене/запис на данни. В противен случай не бихме могли да кажем, че моделът е независим. Моделът е набор от тясно свързани класове, до които нито изгледът, нито контролерът трябва да имат достъп. За да свържем модела с изгледа и контролера, трябва да внедрим шаблона за дизайн на фасадата. Фасадата на модела е слоят между модела и потребителския интерфейс, чрез който изгледът получава удобно форматирани данни, а контролерът променя данните, като извиква необходимите методи на фасадата. В крайна сметка всичко изглежда така:
MVC: Какво печелим?
Основната цел на MVC парадигмата е да отдели внедряването на бизнес логиката (модела) от нейната визуализация (изгледа). Това разделяне увеличава възможностите за повторно използване на codeа. Ползите от MVC са най-очевидни, когато трябва да представим едни и същи данни в различни формати. Например като table, графика or диаграма (използвайки различни изгледи). В същото време, без да засягаме начина, по който се изпълняват изгледите, можем да променим начина, по който реагираме на действията на потребителите (щраквания върху бутони, въвеждане на данни). Ако следвате принципите на MVC, можете да опростите разработката на софтуер, да увеличите четливостта на codeа и да подобрите разширяемостта и поддръжката. В последната статия от поредицата „Въведение в развитието на предприятието“ ще разгледаме реализация на MVC, изградена с помощта на Spring MVC. Част 8. Нека напишем малко приложение с помощта на Spring Boot
В тази статия ще се запознаем с нещо, наречено MVC. Ще говорим Howво е MVC, ще се докоснем до неговата история, ще проучим основните идеи и концепции, въплътени в MVC, ще разгледаме стъпка по стъпка How да разделим приложение на модули Model, View и Controller, ще напишем малко уеб приложение, използващо Spring Boot, и като използвате Spring MVC като пример, вижте How данните се изпращат от Java code към HTML страници. За да разберете този материал, трябва да сте запознати с дизайнерските модели, особено наблюдателя и фасадата. И да сте запознати с HTTP заявките и отговорите, да разбирате основите на HTML и да знаете Howво представляват анотациите на Java. Вземете чаша кафе и лека закуска и се настанете удобно. Нека да започнем.
От всичко това можем да направим логичен извод. Една сложна система трябва да бъде разделена на модули. Нека опишем накратко стъпките за постигане на това разделяне.
Ето How стигаме до приложение, състоящо се от три модула, наречени модел, изглед и контролер. Нека обобщим:
