Схема архитектуры laravel?

может ли кто-нибудь указать мне на диаграмму, которая показывает связь между обычными битами MVC и следующим:

  • промежуточное
  • гвардии
  • фасады
  • договоры

фреймворк Laravel, кажется, так много посредников и я борюсь, чтобы увидеть большую картину.

редактировать

подумав об ответе Алекса (ниже) я думаю, что такие схемы is вероятный. Поскольку некоторые из них относятся к общим принципам ООП, я думаю, что диаграмма последовательности UML будет ответом.

16
laravel-5

2 ответов

поскольку ваш вопрос очень широк, я думаю, что предоставление объяснения для всех в одном изображении было бы похоже на наличие всего вкуса в одном торте. @Alex в вышеуказанном ответе, уже покрыли объяснение точно. Вот мой дубль:

MVC : шаблон проектирования рекомендует разработчику не смешивать бизнес-логику (модель) с представлением (представлением) и с запросами пользователя (контроллер).

запомните :

MVC stands for Model, View and Controller.
Model is responsible for maintaining application data and business logic.
View is a user interface of the application, which displays the data.
Controller handles user's requests and renders appropriate View with Model data

более детально : http://www.tutorialsteacher.com/mvc/mvc-architecture

термины: middleware, предохранители, фасады, контракты часть логики применения рамок Laravel для цикла запроса на различных использовани-случаях, для того чтобы отделить коды в применении улучшить ремонтопригодность, понимать-способность и сплоченность. Хотя даже одного скрипта страницы достаточно, чтобы сделать необходимую работу, но это будет головная боль для поддержания.

промежуточное: путь Laravel для фильтрация HTTP-запросов, входящих в приложение. Оно усаживает после маршрутизатора и перед регулятором в жизненном цикле запроса.

Подробнее : https://laravel.com/docs/5.6/middleware

гвардии : они определение того, как система должна хранить и извлекать информацию о пользователях при регистрации и аутентификации.

Подробнее : https://laravel.com/docs/5.6/authentication

фасады : фасады обеспечивают "статический" интерфейс для классов, доступных в сервисном контейнере приложения. https://laravel.com/docs/5.6/facades

контрактов : надежность соединения и простоту. Контракты Laravel-это набор интерфейсов, определяющих основные услуги, предоставляемые платформой. Например, подсветка\контракты\очередь\Очередь контракт определяет методы, необходимые для заданий очереди, а контракт Illuminate\Contracts\Mail\Mailer определяет методы, необходимые для отправки электронной почты.

больше деталей:https://laravel.com/docs/5.6/contracts

enter image description here

0

извините. Это не ответ. Но только мнение.

вы пытаетесь сравнить " яблоки "с"апельсинами".

концепция MVC-это концепция, связанная конкретно или в основном с веб-разработкой.

он рекомендует разработчику не смешивать контент (модель) с представлением (представлением) и с логикой (контроллером).

С другой стороны, вы упомянули: промежуточное ПО, охранники, фасады, контракты.

они все в основном о general концепции программирования и добрая часть или расширения принципов ООП.

давайте не будем говорить о ваших конкретных условиях:middleware, Guards, facades, Contracts, но только о ОП.

любой принцип ООП может быть применен к любой части MVC.

мы можем создать модель, используя ООП (классы, интерфейсы и т. д.), Или мы можем сделать это каким-то процедурным способом или смешать ООП, процедурные и классические спагетти.

же о View и Controller. Вы можете использовать некоторые принципы ООП и методы или вы можете ограничить их использование или игнорировать их. Это зависит от разработчика и / или, возможно, зависит от объема и дизайна проекта.

возвращаясь к вашему списку: промежуточное ПО, охранники, фасады, контракты. Я бы сказал, что это просто часть большого семейства терминов и практик ООП, существующих в современном мире разработки программного обеспечения. Я имею в виду, к сожалению, мы не можем проводить параллели между MVC и некоторым списком практик ООП.

еще одна идея, на которую я бы указал, это ООП гораздо более общее, чем программное обеспечение MVC, WEB и data-representation-logic.

допустим, нам нужно разработать новое ядро ОС. Я бы сказал, что для такого приложения нет места для применения MVC. Но ОП все еще может быть полезен. То же самое касается встроенных систем или определенного программного обеспечения, драйверов, серверов и т. д...

1