Този материал е част от поредицата "Въведение в развитието на предприятието". Предишни статии:
В тази статия ще се запознаем с нещо, наречено MVC. Ще говорим Howво е MVC, ще се докоснем до неговата история, ще проучим основните идеи и концепции, въплътени в MVC, ще разгледаме стъпка по стъпка How да разделим приложение на модули Model, View и Controller, ще напишем малко уеб приложение, използващо Spring Boot, и като използвате Spring MVC като пример, вижте How данните се изпращат от Java code към HTML страници. За да разберете този материал, трябва да сте запознати с дизайнерските модели, особено наблюдателя и фасадата. И да сте запознати с HTTP заявките и отговорите, да разбирате основите на HTML и да знаете Howво представляват анотациите на Java. Вземете чаша кафе и лека закуска и се настанете удобно. Нека да започнем.
От всичко това можем да направим логичен извод. Една сложна система трябва да бъде разделена на модули. Нека опишем накратко стъпките за постигане на това разделяне.
Ето How стигаме до приложение, състоящо се от три модула, наречени модел, изглед и контролер. Нека обобщим:
- относно работата в мрежа
- за софтуерната архитектура
- за HTTP/HTTPS
- относно основите на Maven
- относно сървлети (писане на просто уеб приложение)
- относно контейнерите за сервлети

История на 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

Стъпка 1. Отделете бизнес логиката на приложението от потребителския интерфейс
Основната идея на MVC е, че всяко приложение с потребителски интерфейс може да бъде разделено на 2 модула: модул, отговорен за внедряването на бизнес логиката, и потребителски интерфейс. Първият модул ще реализира основната функционалност на приложението. Този модул е ядрото на системата, където е реализиран домейн моделът на приложението. В MVC парадигмата този модул е буквата М, тоест моделът. Вторият модул реализира целия потребителски интерфейс, включително логиката за показване на данни на потребителя и управление на взаимодействието на потребителя с приложението. Основната цел на това разделяне е да се гарантира, че ядрото на системата („моделът“ в терминологията на MVC) може да бъде независимо разработено и тествано. След като направите това разделяне, архитектурата на приложението изглежда така:
Стъпка 2 Използвайте модела на наблюдателя, за да направите модела още по-независим и да синхронизирате потребителските интерфейси
Тук имаме 2 цели:- Постигнете още по-голяма независимост на модела
- Синхронизирайте потребителските интерфейси
Стъпка 3 Разделете интерфейса на изглед и контролер
Продължаваме да разделяме приложението на модули, но вече на по-ниско ниво в йерархията. На тази стъпка потребителският интерфейс (който отделихме в отделен модул в стъпка 1) се разделя на изглед и контролер. Начертаването на строга граница между изгледа и контролера е трудно. Ако кажем, че изгледът е това, което потребителят вижда, а контролерът е механизмът, който позволява на потребителя да взаимодейства със системата, може да посочите противоречие. Контролните елементи, като бутони на уеб page or виртуална клавиатура на екрана на телефона, са основно част от контролера. Но те са толкова видими за потребителя, колкото всяка част от изгледа. Това, за което наистина говорим тук, е функционално разделяне. Основната задача на потребителския интерфейс е да улесни взаимодействието на потребителя със системата.- извежда и показва удобно системна информация на потребителя
- въведете потребителски данни и команди (съобщете ги на системата)

- Съгласно принципите на MVC парадигмата, системата трябва да бъде разделена на модули.
- Най-важният и независим модул трябва да бъде моделът.
- Моделът е ядрото на системата. Трябва да е възможно да се разработи и тества независимо от потребителския интерфейс.
- За да постигнем това, в първата стъпка на разделянето трябва да разделим системата на модел и потребителски интерфейс.
- След това, използвайки модела на наблюдател, ние укрепваме независимостта на модела и синхронизираме потребителските интерфейси.
- Третата стъпка е да разделите потребителския интерфейс на контролер и изглед.
- Всичко, което е необходимо за получаване на потребителски данни в системата, е в контролера.
- Всичко, което е необходимо за предоставяне на информация на потребителя, е в изгледа.
Малко за това How изгледът и контролерът взаимодействат с модела
Чрез въвеждане на информация през контролера, потребителят променя модела. Или поне потребителят променя данните на модела. Когато потребителят получава информация чрез интерфейсни елементи (чрез изгледа), потребителят получава информация за модела. How става това По Howъв начин изгледът и контролерът взаимодействат с модела? В крайна сметка класовете на изгледа не могат директно да извикват методите на класовете на модела за четене/запис на данни. В противен случай не бихме могли да кажем, че моделът е независим. Моделът е набор от тясно свързани класове, до които нито изгледът, нито контролерът трябва да имат достъп. За да свържем модела с изгледа и контролера, трябва да внедрим шаблона за дизайн на фасадата. Фасадата на модела е слоят между модела и потребителския интерфейс, чрез който изгледът получава удобно форматирани данни, а контролерът променя данните, като извиква необходимите методи на фасадата. В крайна сметка всичко изглежда така:
GO TO FULL VERSION