Model-VIew-Controller (MVC) шаблоны проектирования. Архитектурный шаблон
Vložit
- čas přidán 25. 08. 2020
- Controller - точка входа в приложение, выполняет подготовительные и предохранительные от взлома обязанности. Конвертирует request в framework agnostic DTO для обращение в доменный слой приложения. Результат работы домена конвертирует во viewDTO и делегирует отрисовку на view слой. Результат работы view слоя отправляет как responce. Любое исключение должно быть отработано и конвертировано в соответствующий ответ от сервера.
Model - самое ценное в приложение, то ради чего реализуются проекты. Эта часть приложения в идеальном мире не должна пересекаться с частями фреймворка. Через инверсию зависимости soliD в модели передаются реализации для работы с файловой системой и БД.
View - слой представления, в современных API приложениях, когда backend отдает json этот слой сильно исхудал. В Backen приложениях выделяется отдельный слой для работы по конвертации чистых данных в удобный человеку формат (HTML/JSON/XML...)
Понимание архитектуры MVC позволит Вам успешно пройти собеседование на backend developer и построить удобную для дальнейшего расширения архитектуру приложения.
Презентация docs.google.com/presentation/...
Логическое продолжение - изучение MVVM, смотрите в этом видео czcams.com/video/KUXVf1-6JXQ/video.html
Самое доступное видео о Model-VIew-Controller (MVC). Пожалуй, подпишусь на канал. )))
Спасибо)
Приятного просмотра 😎
Ставь лайк если уже знал, что такое MVC 😅
Пиши коммент если не знал 😜
Не знал . Спасибо большое за такие чудесные уроки !!!
Знал но не так подробно) По NestJs буду смотреть и tdd, когда с паттернами разберусь
спасибо большое за объяснение. Начинаю изучать MVC. Схемы очень хорошие
Да, это абсолютно верный подход, уже не говоря о том, что если всю логику по работе с запросами пихать в контроллер, то это будет просто огромный, плохочитаемый кусок кода😁
Круто, про MVVM в ангуляре бы еще такое
Будет по MVVM :) и в angular)
czcams.com/video/KUXVf1-6JXQ/video.html
По MVVM видео) немного об Angular упоминал в видео
Самое толковое объяснение
Спасибо большое!
Огромное спасибо!!!!
Прикольный урок, было бы интересно узнать на какой уровень слушателя рассчитан (понятно, что новичку маст хев, но не у всех новичков есть понимание как магия на беке происходит).а вообще очень интересно.
Это самое новичковое видео, это самое первое что спрашивают на собесе для backend разраба. (кроме кусочка где я все паттерны перечисляю в моделях) Вот дальше пойдут паттерны для опытных и(или) любопытных...там будет тяжело 🙄 но я буду стараться сделать понятно и интересно 😎
Привет, классно объяснил, всё понятно! Есть вопрос, что в этой модели является сервисным слоем?
По классике все кто начинают не выделяют сервисный слой вообще
Если система заставляет делать сервисы, то это считается буква M
M -> Сервисы как логика и Data Model как данные над которыми можно производить работу.
Везде где работают с ООП скажут, что контроллер должен быть тонким. Т.е. слой сервисов там быть не может
SOA (Service Oriented Architecture) евангелисты, даже тут могли бы сказать что сервисы это не модели и должен быть паттерн MVCS (букву S втулить куда больше нравится)
Если ваша архитектура это слоенный пирог, то наверняка даже сервисы уровня контроллера будут...т.е.
Application layer Services - сервисы уровня приложения
Domain Layer Services - сервисы уровня бизнес моделей
Вывод...все сложно и не однозначно :) у нас используется последний вариант)
@@grommaks спасибо за развернутый ответ, правильно ли я понял, что такое сервисный слой, если скажу, что сервисный слой служит дополнительным слоем между контроллером и моделью, цель которого закешировать (если надо) запрос, что бы лишний раз не дергать db, обратится к другим сервисам, например мы удаляем пользователя и сервис дернет другие сервисы, которые удалят записи об этом пользователе из других частей db, дождется от всех ответов и передаст полученное контроллеру, тем самым позволит сделать контроллер тонким
и еще вопрос, какое основное отличие тонкого контроллера от толстого? разделение ответственностей? если например 3 контроллера, первый проверяет url, второй проверяет права доступа (токен и т.д.), и третий уже принимает реквест, это тонкие контроллеры или нет?
@@student7368 Отвечу с конца) Если мы говорим о backend. То контроллер будет всего один...
Его ответственность я описал в видео, все что уходит за пределы этой ответственности это уже толсто...
1) Принять валидный реквест (валидация как правило в самом реквесте делается еще до контроллера)
2) Сообщить всему миру что он работает (вызвать события, чтобы в будущем можно было расширять, это как правило на уровне ядра и так происходит, можно забить на этот пункт)
3) Обратиться к доменному слою (к моделькам, сделать работу)
4) Конвертировать ответ доменного слоя, и скормить его в слой отображения
5) Вернуть красивый результат тому, кто воспользовался контроллером.
6) В случае исключений в доменном слое правильно обработать ошибки.
Это все как правило в одном классе и это контроллер (тонки)
Контроллер не должен
Реализовывать логику которая потенциально может быть использована повторно в CLI (там не будет реквеста, контроллер использовать будет невозможно) или другом сервисе как часть бизнес логики.
Контроллер не должен делать проверки что при таком адресе электронной почты в запросе на обновление пользователя мы должны отправить на одно а 2 письма потому что так хочет бизнес...
Теперь по первому комменту.
Если мы говорим про bacend то кеша в сервисном слое быть не должно, это типа как чистые функции) так их будет легко тестировать и беды никогда не случится.
С фронтом там уже все сделано до нас по поводу кеширования, там тоже практически не нужно кешировать в сервисном слое.
Репозиторий отвечает за правильную загрузку и сохранение моделей в хранилище.
Контроллер принимает запрос по API
Все что между - сервисы в том или ином виде.
Если мы используем ActiveRecord, то часто суют логику именно в модель, из-за чего модели достигают 4 000 + строк через пару месяцев работы.
В приложении есть логика хеширования пароллей и их валдация. Не нужно ее тулить в Active Record, ведь это может пригодится и в других бизнес случаях.
В приложении есть логика генерации уникальной поисковой строки для продукта в магазине из его имени. Это будет сервис, который приймет модель продукта и определит поле url_key уникальным образом.
В приложении есть логика смены пола пользователем, сервис проверит или обновит имена и фамилии согласно локализации.
Если обратиться к аналогиям с реальной жизнью...
Представте обычный магазин. Вы курьер, т.е. Вы сервис Курьера...и Вам поступает модель = список покупок.
Вы идете по магазину и согласно списку набираете товары. Вы делегируете проверку срока годности сервису проверки годности. Вы не имеете доступа к колбасе, вы делегируете приватные товары в сервис приватных товаров. Вы полученный набор моделей продуктов передаете на сервис кассы и вам формирует чек. Вы делегируете оплату сервису вашего банка. При успешной опате вы формируете пакет с продуктами и возвращаете его тому кто вас попросил в начале.
Т.е. есть модели и есть службы...эти службы их целый зоопарк из разных семейств паттернов программирования, но их объединяет то, что они не имеют собстенного состояния, а как правило работают с входящими данными.
P.S. сервисный подход много чего взял из функционального программирования или из просто процедурного программирования. Где есть функции и структуры данных.
Зачем же тогда сервисы?
1) легко тестировать
2) настраиваются через конструктор и никогда больше не меняются
3) можно переиспользовать с разными параметрами конструктора (не плодится новый код)
4) через DI легко перенастраивается конструктор или даже вообще заменяется на другие реализации
@@grommaks все программирование во все времена это попытка определить абстракции, оперировать строго на их уровнях и позволить "себе крутому" (фреймворк, паттерн) немного вылезти за их рамки. Если контролер это тонкий уровень, а перед ним мы делаем валидацию, видимо обращаясь к сервису валидации, то не течет ли наша абстракция ещё до входа в MVC? ))
Service, strategy, decorator, entity, dto, repository, а какие проблемы эти шаблоны решают для практического применения? В книге есть про tdd?
service это изолированная логика, часто сервис вопринимается как модель без состояния или модель хранящаяя бизнес логику. И часто воспринимается как некоторое надмножество над остальными поведенчискими паттернами
strategy позволяет внедрять бизнес логику в некоторые точки расширения. Меняя стратегию в некотором объекте, мы меняем как она работает. Например данные из таблицы в бд мы хотим отправить в браузер, мы можем использовать разные стратегии чтобы сделать это как эксель файл, или как html и так далее
decorator делает то же что и стратегия частично, но только снаружи, без надобности иметь эту самую точку расширения. decorator более сложный в реализации и обязан повторить все публичные методы декорируемого объекта. Суть в том, чтобы добавить логики перед вызовом методов или после них. В JavaScript декораторы делаются очень и очень легко, потому что методы это просто функции которые можно заменять, что нельзя делать в Java или C#
entity - это некоторый класс который знает как имея лишь entity_id собрать все данные для его целостного вида. Этот класс защищает свои данные путем инкапсуляции, entity в большинстве современных фреймворков это анемичные модели, что не имеют ничего общего с оригинальным паттерном...или это active record.
dto это типизированная модель для того чтобы передавать данные от слоя к слою, задача быть созданной и переданной как параметр в другой объект...все
repository - это паттерн для доступа к хранилищу данных, у него как правило есть 4ре метода, get / save / delete / getList
Но бывают и другие наборы методов
Задача репозитория, скрыть используемое хранилище данных. Например мы делаем быстрое решение которые ходит в стороннюю АПИ, через месяц мы выкачаем данные в нашу БД, и этот же репозиторий будет ходить в нашу собственную АПИ. При этом кроме реализации репозитория ничего меняться не должно в нашем приложении.
Согласен, что стоит отснять уроки и по этим паттерам. Спасибо за то, что спрашиваете, мотивируете)
Про TDD не помню что за книга, видео снимал давно, привязки ко времени нет в вашем запросе, по TDD посмотрите мои 5 видео по Dependency Injection в JavaScript
@@grommaks круто спасибо за развернутые ответы вы супер. Сейчас запишу в тетрадь и бегом в nestjs. Я не думал что найду в you tube крутые курсы по паттернам nestjs, angular, игру 2048 я уже отчался было( Осталось только понять как реализовать authorization autentification spa nestjs+angular rest api с jwt outh2 с csrf helmet.