Въведение в MVC архитектурата
Най-популярната архитектура на applicationsта, за която всеки програмист знае, е MVC . MVC означава Model-View-Controller .
Това не е толкова архитектурата на applicationsта, колкото архитектурата на компонентите на приложението, но ще се върнем към този нюанс по-късно. Какво е MVC?
MVC е схема за разделяне на данните на приложението и контролната логика на три отделни компонента – модел, изглед и контролер – така че всеки компонент да може да се модифицира независимо.
- Модел (Model) предоставя данни и отговаря на команди на контролера, като променя състоянието си.
- Изгледът е отговорен за показването на данните за модела на потребителя в отговор на промените в модела.
- Контролерът (контролер) интерпретира действията на потребителя, уведомявайки модела за необходимостта от промени.
Този модел е изобретен през 1978 (!) Година. Да, проблемите с правилната софтуерна архитектура бяха актуални преди 50 години. Ето How този модел е описан от диаграмата в оригинала:
Моделът предоставя данни и методи за работа с тях: заявки към базата данни, проверка за коректност. Моделът е независим от изгледа (не знае How да рендира данни) и контролера (няма точки за взаимодействие с потребителя), като осигурява достъп до и управление на данни.
Моделът е изграден по такъв начин, че да отговаря на заявки, като променя състоянието си, като може да бъде вградено известяване на „наблюдатели“. Моделът, поради независимост от визуалното представяне, може да има няколко различни представяния за един „модел“.
Изгледът отговаря за получаването на необходимите данни от модела и изпращането им на потребителя. Изгледът не обработва въвеждане от потребителя.
Контролерът осигурява "комуникацията" между потребителя и системата. Контролира и насочва данните от потребителя към системата и обратно. Използва модел и изглед за изпълнение на желаното действие.
Има известна трудност с факта, че този модел е еволюирал малко през десетилетията. Тоест името остана същото, но целта на частите започна да се променя.
MVC архитектура в мрежата
Идеята зад шаблона за проектиране на MVC е много проста: трябва ясно да разделим отговорността за различни поведения в нашите applications:
Модел— обработка на данни и логика на приложението.
изглед— предоставяне на данни на потребителя във всеки поддържан формат.
контролер- обработка на потребителски заявки и извикване на съответните ресурси.
Приложението е разделено на три основни компонента, всеки от които отговаря за различни задачи. Нека разгледаме по-подробно компонентите на приложение клиент-сървър, използвайки пример.
Контролер
Потребителят кликва върху различни елементи на pageта в браузъра, в резултат на което браузърът изпраща различни HTTP заявки: GET, POST or други. Контролерът може да включва браузъра и JS codeа, които работят вътре в pageта.
Основната функция на контролера в този случай е да извиква методи на необходимите обекти, да управлява достъпа до ресурси за изпълнение на задачи, зададени от потребителя. Обикновено контролерът извиква подходящия модел за задачата и избира подходящия изглед.
Модел
Моделът в широк смисъл са данните и правилата, които се използват за работа с данните – заедно те изграждат бизнес логиката на приложението. Проектирането на приложение винаги започва с изграждането на модели на обектите, върху които работи.
Да кажем, че имаме онлайн магазин, който продава книги, тогава едно лице само потребител на приложение ли е or също и автор на книга? Тези важни въпроси трябва да бъдат разгледани по време на проектирането на модела.
Освен това има набори от правила: Howво може да се направи, Howво не може да се направи, кои набори от данни са приемливи и кои не. Може ли една книга да съществува без автор? А авторът без книги? Може ли датата на раждане на потребителя да е през 300 година и т.н.
Моделът дава на контролера изглед на данните, които потребителят е поискал (съобщение, page от книга, снимки и др.). Моделът на данните ще бъде един и същ, независимо How искаме да го представим на потребителя. Затова избираме всеки наличен изглед за показване на данните.
Моделът съдържа най-важната част от логиката на нашето приложение , логиката, която решава проблема, с който се занимаваме (форум, магазин, банка и т.н.). Контролерът съдържа най-вече организационна логика за самото приложение (точно като вашия Project Manager).
Преглед
View предоставя различни начини за представяне на данните, получени от модела. Това може да бъде шаблон, който е пълен с данни. Може да има няколко различни изгледа и контролерът избира кой е най-подходящ за текущата ситуация.
Уеб приложението обикновено се състои от набор от контролери, модели и изгледи. Контролерът може да бъде само на бекенда, но може да има и вариант от няколко контролера, когато логиката му е разпръсната и върху фронтенда. Добър пример за този подход е всяко мобилно приложение.
Пример за MVC в мрежата
Да приемем, че трябва да разработите онлайн магазин, който ще продава книги. Потребителят може да извършва следните действия: да разглежда книги, да се регистрира, да купува, да добавя артикули към текущата поръчка, да маркира книги, които харесва и да ги купува.
Вашето приложение трябва да има модел , който отговаря за цялата бизнес логика. Нуждаете се и от контролер , който ще обработва всички потребителски действия и ще ги превръща в извиквания на метод от бизнес логиката. Един метод на контролера обаче може да извика много различни методи на модела.
Имате нужда и от набори от изгледи: списък с книги, информация за една книга, количка за пазаруване, списък с поръчки. Всяка page от уеб приложение всъщност е отделен изглед, който показва определен аспект на модела на потребителя.
Нека да видим Howво се случва, ако потребител отвори списък с препоръчани от книжарницата книги, за да види заглавия. Цялата последователност от действия може да бъде описана под формата на 6 стъпки:
стъпки:
- Потребителят кликва върху връзката „препоръчани“ и браузърът изпраща заявка до, да речем, /books/recommendations.
- Контролерът проверява заявката : потребителят трябва да е влязъл. Или трябва да имаме колекции от книги за невлезли потребители. След това контролерът извиква модела и го моли да върне списъка с книги, препоръчани на потребител N.
- Моделът осъществява достъп до базата данни, извлича информация за книги от там: книги, които са популярни в момента, книги, закупени от потребителя, книги, закупени от неговите приятели, книги от неговия списък с желания. Въз основа на тези данни моделът изгражда списък от 10 препоръчани книги и ги връща на контролера.
- Контролерът получава списък с препоръчани книги и го разглежда. На този етап контрольорът взема решения! Ако има малко книги or списъкът е напълно празен, той изисква списък с книги за невлязъл потребител. Ако в момента се провежда промоция, администраторът може да добави промоционални книги към списъка.
- Контролерът определя коя page да покаже на потребителя. Това може да бъде page за грешка, page със списък с книги, page с поздравления, че потребителят е станал мorонен посетител.
- Сървърът дава на клиента избраната от контролера page ( изглед ). Попълва се с необходимите данни (потребителско име, списък с книги) и отива при клиента.
- Клиентът получава pageта и я показва на потребителя.
Какви са предимствата на този подход?
Най-очевидното предимство, което получаваме от използването на концепцията MVC, е ясното разделяне на логиката на представяне (потребителски интерфейс) и логиката на приложението (бекенд).
Второто предимство е разделянето на сървърната част на две: интелигентен модел ( изпълнител ) и контролер ( център за вземане на решения ).
В предишния пример имаше момент, в който контролерът можеше да получи празен списък с препоръчани книги от модела и да реши Howво да прави с него. Теоретично тази логика може да бъде поставена директно в модела.
Първо, когато иска препоръчани книги, моделът ще реши Howво да прави, ако списъкът е празен. След това ще трябва да добавя codeа на същото място, Howво да направя, ако в момента тече промоция, след това още различни опции.
След това се оказа, че администраторът на магазина иска да види How ще изглежда pageта на потребителя без промоция or обратното, сега няма промоция, но иска да види How ще се показва бъдещата промоция. А методи за това няма. Затова беше решено центърът за вземане на решения (контролер) да се отдели от бизнес логиката (модела).
В допълнение към изолирането на изгледи от логиката на приложението, концепцията MVC значително намалява сложността на големите applications. Кодът е много по-структуриран, което улеснява поддръжката, тестването и повторното използване на решения.
Разбирайки концепцията на MVC, вие като разработчик осъзнавате къде трябва да добавите сортиране на списъка с книги:
- На ниво заявка към базата данни.
- На ниво бизнес логика (модел).
- На ниво бизнес логика (контролер).
- В изгледа - от страна на клиента.
И това не е риторичен въпрос. Точно сега помислете къде и защо трябва да добавите codeа за сортиране на списъка с книги.
Класически MVC модел
Взаимодействието между MVC компонентите се реализира по различен начин в уеб applicationsта и мобилните applications. Това е така, защото уеб приложението е краткотрайно, обработва една потребителска заявка и излиза, докато мобилното приложение обработва много заявки без рестартиране.
Уеб applicationsта обикновено използват „пасивния“ модел, докато мобилните applications използват „активния“ модел. Активният модел, за разлика от пасивния, ви позволява да се абонирате и да получавате известия за промени в него. Това не е необходимо за уеб applications.
Ето How изглежда взаимодействието на компонентите в различните модели:
Мобилните applications (активен модел) активно използват събития и механизма за абонамент за събития. С този подход изгледът ( view ) се абонира за промените в модела. След това, когато възникне няHowво събитие (например, потребителят щракне върху бутон), контролерът се извиква . Той също така дава на модела команда за промяна на данните.
Ако някои данни са се променor, тогава моделът генерира събитие за промяна на тези данни. Всички изгледи, които са се абонирали за това събитие (за които е важно да промените тези конкретни данни), получават това събитие и актуализират данните в своя интерфейс.
В уеб applicationsта нещата са организирани малко по-различно. Основната техническа разлика е, че клиентът не може да получава съобщения от страната на сървъра по инициатива на сървъра .
Следователно контролерът в уеб приложение обикновено не изпраща ниHowви съобщения до изгледа, но дава на клиента нова page, която технически е нов изглед or дори ново клиентско приложение (ако едната page не знае нищо за другата) .
Понастоящем този проблем е частично решен чрез следните подходи:
- Редовно запитване на сървъра за промени във важни данни (веднъж на minutesа or повече).
- WebSockets позволяват на клиента да се абонира за сървърни съобщения.
- Уеб насочени известия от страната на сървъра.
- Протоколът HTTP/2 позволява на сървъра да инициира изпращането на съобщения до клиента.