архитектура сложных веб приложений с примерами на laravel
Архитектура сложных веб-приложений. С примерами на Laravel
Эта книга не пособие. Много шаблонов описаны поверхностно, с целью просто познакомить читателя с ними. Более подробное описание можно найти по ссылкам в конце.
Книга читается легко и с интересном, никакой воды, наоборот, иногда хочется продолжения и углубления в тему, больше примеров, но Адель оставляет нам это на самостоятельную проработку.
Вот некоторые из интересных вопросов, рассмотренных в книге.
Какие ограничения несёт в себе мышление в стиле Create, Read, Update, Delete (CRUD)?
Забавно, что в одном из подкастов, который я когда-то слушал (уже не вспомню какой точно), создатель Laravel, Taylor Otwell подметил, что все его приложения отлично укладываются в модель CRUD, а если нужно что-то иное, какой-то отличное от этого действие, то скорее он что-то делает не так. Вот такая полярность мнений.
Опасность наследования и концепция: класс должен быть либо финальным, либо абстрактным. Сильно поддерживаю, не раз обжигался на наследовании конкретных реализаций и с опытом пришел к такому же выводу: если наследоваться, то только от абстрактного класса.
Польза от внедрения зависимостей и когда оно не нужно? А статические методы — есть ли для них место под солнцем?
Трейты. Адель рассмотрел трейты со всех сторон, когда они уместны и когда бесполезны.
Однако, приведу небольшую цитату, к которой у меня остались вопросы:
Я не люблю Трейты. Они могут с успехом использоваться в классах тестов, поскольку там нет хорошей причины организовывать полноценное DI, но лучше избегать их использования в главном коде приложения. Трейты — это не ООП, а чистые ООП решения всегда будут более естественными.
Тут хочется переспросить, что такое «чистые ООП решения»? Борцы за чистоту ООП скажут, что наше ООП — это вообще не ООП, которое имел в виду отец-основатель настоящего ООП Алан Кей! С другой стороны, напирают адепты настоящего ООП, прочитавшие книгу Elegant Objects Егора Бугаенко.
Поэтому я всегда насторожено отношусь к формулировкам, которые делают отсылки к определению ООП. Трейты — это не ООП? Зависит от вашей ООП конфессии!
Отлично описаны вопросы передачи данных запроса внутрь приложения с помощью DTO.
А также валидация. Валидация с помощью Form Requests, валидация непосредственно в сервисах, валидация с помощью аннотаций в Symfony, и валидация в конструкторах Value Objects.
Если мыслить объектами и грамотно применять Value Objects для представления данных — это всё усложнит или всё упростит, в чём профит?
Обработка ошибок, что выбрать — повсеместно использовать исключения или возвращать Optional значения? Вообще, возврат Optional имеет много плюсов и активно используется в функциональных языках программирования, но несколько чужд нам, в экосистеме PHP.
Про исключения Адель отлично разложил по полочкам чем отличаются проверяемые и не проверяемые исключения — это два типа исключений, которые явно реализованы в синтаксисе Java. В PHP явного деления нет, но PhpStorm даёт нам подсказки, опираясь на ту же модель проверяемых и не проверяемых исключений. Очень полезная глава для понимания, как обрабатывать различные типы ошибок.
События и чем неудобны события Eloquent. Лучше использовать свои собственные доменные события.
Тестирование. С Unti тестированием простых чистых функций всё просто, но что делать с тестирование сервисов, имеющих много зависимостей и как не утонуть в коде, конфигурирующем все эти зависимости в виде моков и стабов? Из-за желания написать Unit тесты на относительно сложные сервисы, иногда мы обрастаем излишними абстракциями, код самого приложения становится сложнее чем хотелось бы и чем он мог бы быть.
Что делать? Менять подход к написанию сервисов и отделить слой приложения от доменной логики. Читая книгу, мы от unti-тестирования сервисов плавно переходим к DDD и возвращаемся к unit-тестированию, но уже доменного слоя и тут всё встаёт на свои места. Только от этого не становится легче, т.к. это уже не похоже на типичное Laravel приложение. Кажется, что уже проще писать сразу на Symfony, чтобы все эти советы применить.
Вынесение доменной логики — это большой шаг в эволюции проекта. Намного более практично делать его в самом начале, но архитектор должен оценить сложность этой логики. Если приложение — это простой CRUD с очень небольшой дополнительной логикой, то от доменного слоя будет мало толку.
Вспоминая слова Тейлора, что он практически любую логику своих приложений успешно вписывает в CRUD, всё становится на свои места.
Последние две главы про CQRS и Event Sourcing с неплохими примерами.
Так что рекомендую к прочтению: «Архитектура сложных веб-приложений. С примерами на Laravel», автор Adel Faizrakhmanov. Книга доступна на русском и на английском.
В заключение, оставлю заключение к самой книге:
Эта книга просто некий обзор практик, которые мне показались полезными при разработке приложений. Возможно, кому-то она поможет выбрать нужную для своего проекта. Главное, понять, что книга не о том, что надо каждое приложение взять и переписать с использованием, например, Event Sourcing. К каждому приложению нужен свой подход и одни и те же практики отлично подходят к одним приложениям, но будут вредны для других.
Архитектура сложных веб-приложений. С примерами на Laravel
Эта книга не пособие. Много шаблонов описаны поверхностно, с целью просто познакомить читателя с ними. Более подробное описание можно найти по ссылкам в конце.
Книга читается легко и с интересном, никакой воды, наоборот, иногда хочется продолжения и углубления в тему, больше примеров, но Адель оставляет нам это на самостоятельную проработку.
Вот некоторые из интересных вопросов, рассмотренных в книге.
Какие ограничения несёт в себе мышление в стиле Create, Read, Update, Delete (CRUD)?
Забавно, что в одном из подкастов, который я когда-то слушал (уже не вспомню какой точно), создатель Laravel, Taylor Otwell подметил, что все его приложения отлично укладываются в модель CRUD, а если нужно что-то иное, какой-то отличное от этого действие, то скорее он что-то делает не так. Вот такая полярность мнений.
Опасность наследования и концепция: класс должен быть либо финальным, либо абстрактным. Сильно поддерживаю, не раз обжигался на наследовании конкретных реализаций и с опытом пришел к такому же выводу: если наследоваться, то только от абстрактного класса.
Польза от внедрения зависимостей и когда оно не нужно? А статические методы — есть ли для них место под солнцем?
Трейты. Адель рассмотрел трейты со всех сторон, когда они уместны и когда бесполезны.
Однако, приведу небольшую цитату, к которой у меня остались вопросы:
Я не люблю Трейты. Они могут с успехом использоваться в классах тестов, поскольку там нет хорошей причины организовывать полноценное DI, но лучше избегать их использования в главном коде приложения. Трейты — это не ООП, а чистые ООП решения всегда будут более естественными.
Тут хочется переспросить, что такое «чистые ООП решения»? Борцы за чистоту ООП скажут, что наше ООП — это вообще не ООП, которое имел в виду отец-основатель настоящего ООП Алан Кей! С другой стороны, напирают адепты настоящего ООП, прочитавшие книгу Elegant Objects Егора Бугаенко.
Поэтому я всегда насторожено отношусь к формулировкам, которые делают отсылки к определению ООП. Трейты — это не ООП? Зависит от вашей ООП конфессии!
Отлично описаны вопросы передачи данных запроса внутрь приложения с помощью DTO.
А также валидация. Валидация с помощью Form Requests, валидация непосредственно в сервисах, валидация с помощью аннотаций в Symfony, и валидация в конструкторах Value Objects.
Если мыслить объектами и грамотно применять Value Objects для представления данных — это всё усложнит или всё упростит, в чём профит?
Обработка ошибок, что выбрать — повсеместно использовать исключения или возвращать Optional значения? Вообще, возврат Optional имеет много плюсов и активно используется в функциональных языках программирования, но несколько чужд нам, в экосистеме PHP.
Про исключения Адель отлично разложил по полочкам чем отличаются проверяемые и не проверяемые исключения — это два типа исключений, которые явно реализованы в синтаксисе Java. В PHP явного деления нет, но PhpStorm даёт нам подсказки, опираясь на ту же модель проверяемых и не проверяемых исключений. Очень полезная глава для понимания, как обрабатывать различные типы ошибок.
События и чем неудобны события Eloquent. Лучше использовать свои собственные доменные события.
Тестирование. С Unti тестированием простых чистых функций всё просто, но что делать с тестирование сервисов, имеющих много зависимостей и как не утонуть в коде, конфигурирующем все эти зависимости в виде моков и стабов? Из-за желания написать Unit тесты на относительно сложные сервисы, иногда мы обрастаем излишними абстракциями, код самого приложения становится сложнее чем хотелось бы и чем он мог бы быть.
Что делать? Менять подход к написанию сервисов и отделить слой приложения от доменной логики. Читая книгу, мы от unti-тестирования сервисов плавно переходим к DDD и возвращаемся к unit-тестированию, но уже доменного слоя и тут всё встаёт на свои места. Только от этого не становится легче, т.к. это уже не похоже на типичное Laravel приложение. Кажется, что уже проще писать сразу на Symfony, чтобы все эти советы применить.
Вынесение доменной логики — это большой шаг в эволюции проекта. Намного более практично делать его в самом начале, но архитектор должен оценить сложность этой логики. Если приложение — это простой CRUD с очень небольшой дополнительной логикой, то от доменного слоя будет мало толку.
Вспоминая слова Тейлора, что он практически любую логику своих приложений успешно вписывает в CRUD, всё становится на свои места.
Последние две главы про CQRS и Event Sourcing с неплохими примерами.
Так что рекомендую к прочтению: «Архитектура сложных веб-приложений. С примерами на Laravel», автор Adel Faizrakhmanov. Книга доступна на русском и на английском.
В заключение, оставлю заключение к самой книге:
Эта книга просто некий обзор практик, которые мне показались полезными при разработке приложений. Возможно, кому-то она поможет выбрать нужную для своего проекта. Главное, понять, что книга не о том, что надо каждое приложение взять и переписать с использованием, например, Event Sourcing. К каждому приложению нужен свой подход и одни и те же практики отлично подходят к одним приложениям, но будут вредны для других.
Советы по оптимизации Laravel-архитектуры с AWS
Перевод статьи подготовлен для студентов профессионального курса «Framework Laravel»
Что такое Laravel Framework
Laravel известен как full stack фреймворк, так как он может выполнять широкий спектр задач: от обслуживания веб-сервисов до управления базами данных и генерации HTML. Вертикально интегрированная среда веб-разработки, которая делает работу более приятной.
Разработчики могут создавать и управлять проектными средами Laravel с помощью инструментов командной строки. Laravel поставляется с Artisangreat, который предоставляет некоторые полезные команды для разработки и может использоваться для генерации кода фреймворка и управления базами данных. Он основан на мощном Symfony-компоненте Console.
Цель Laravel заключается в обеспечении приятного процесса разработки, не жертвуя при этом функциональностью приложения. Счастливые разработчики могут создавать лучший код! Для этой цели мы используем преимущества сильных сторон фреймворка, чтобы сосредоточиться на Laravel, который основан на языках и инструментах разработки таких, как Ruby on Rails, ASP.NET MVC и Sinatra.
Как работает процесс реагирования Laravel?
Типичное приложение Laravel состоит из MVC, упомянутого выше.
При доступе к laravel-приложению браузер отправляет запрос, который принимается веб-сервером и передается в маршрутизатор laravel. После получения запроса маршрутизатором laravel, он перенаправляется в класс-контроллер в соответствии с конфигурацией.
Класс-контроллер принимает запрос. В некоторых случаях он сразу же рендерит представление, являющееся шаблоном, который будет преобразован в HTML и отправлен обратно в браузер. В более общем случае для динамического веб-сайт, контроллер взаимодействует с моделью и связывается с базой данных. После взаимодействия с моделью контроллер рендерит окончательное представление (HTML, CSS и изображения) и возвращает полную веб-страницу в браузер пользователя.
Laravel поддерживает модели, представления и контроллеры, которые должны храниться отдельно для хранения разных файлов в разных каталогах. Именно здесь вступает в игру структура каталогов laravel.
Шаблоны проектирования, такие как MVC, созданы для облегчения работы разработчиков. Именно в этом Laravel лучше PHP, в котором нет никаких шаблонов. Если вам не понятна обсуждаемая тема, не волнуйтесь! Когда вы начнете работать с Laravel, вы даже не поймете, что работаете в шаблоне проектирования. Через некоторое время работать с ними станет естественно.
Модель данных
Модель данных является основой любого приложения, которое реализовывает бизнес-логику. Каждый фрагмент данных представляется таблицей БД. Laravel предоставляет несколько методов для упрощения доступа к ним.
Laravel соединяет модель данных приложения и таблицы базы данных, превращая строки в объекты PHP, которыми легко манипулировать. Это также позволяет вам применять бизнес-правила, описывать отношения между различными моделями данных в вашем приложении и многое другое.
Перенос приложений из Laravel в AWS
Amazon Web Services — одно из самых популярных решений для развертывания приложений на основе Laravel среди опытных PHP-разработчиков. Однако технические аспекты веб-приложений не просты для людей с низким уровнем знаний технологии. Каждый хочет быстро задеплоить идеальную фичу и простое в установке приложение Laravel PHP в облачной инфраструктуре AWS. Следует отметить, что наличие хостинг-провайдера может не только помочь вам, но и поспособствовать легко реализовать бесплатный веб-хостинг и сосредоточиться на создании отличных веб-сайтов.
Понятно, что Cloud Hosting Platform (платформа облачного хостинга) является наилучшим решением для проектных организаций и разработчиков, помогая сэкономить ваше время и ресурсы, что делает его действительно важным для маркетинга и работы онлайн-бизнеса.
Вы можете оптимизировать свой новый управляемый облачный сервер для Laravel PHP в любое время.
Архитектура Laravel на микросервисах
Микросервисы — это стиль архитектуры программного обеспечения, комбинирующий на основе малых строительных блоков, которые сосредоточены на одной ответственности и функции, сложные крупномасштабные Laravel-приложения. Блоки связываются друг с другом, используя независимый от языка набор API. Одной из концепций, которые архитектура микросервисов применяет к стилям архитектуры программного обеспечения Laravel, являются росистые вычисления (Dew Computing), что означает вычислительную мощность многих небольших росинок (представляющих функциональные компоненты микросервисов).
Преимущества микросервисной архитектуры AWS
Да, все, что существует или даже имеет популярность, является таковым не без причины, в этом есть доля правды. Архитектура AWS не исключение! Ее преимущества заключаются в следующем:
Введение в архитектуру и паттерны программирования
Введение
Прежде чем заняться разработкой собственного проекта на основе каркаса приложения Laravel, нам неплохо было бы понять архитектуру каркаса приложения. Некоторые могут спросить: Зачем это нужно? Смысл забивать себе голову разной теоретической чепухой?
Постараюсь ответить на этот вопрос примером из жизни:
Представьте себе, что вы хотите иметь эксклюзивный автомобиль. Естественно он будет строиться на базе некоей серийной модели, но для того, чтобы его построить вам потребуется помощь людей, которые умеют это делать. Вы решаете обратиться к мастерам или даже к фирмам, у которых есть все необходимое: знания, опыт, оборудование и инструмент, но их услуги не дешевы, Ваш бюджет просто не выдержит таких расходов. Тогда вы решаете, что будете строить автомобиль самостоятельно. Отличное решение — правда, вы берете в руки инструмент, плюете на изучение теории, внедряете свои задумки и в итоге…
Я думаю, не стоит описывать, что у вас получится в итоге, ясно только одно — ничего хорошего.
Ну и более приближенный к теме Laravel 4 ответ: Понимание архитектуры приложения, знание основ паттернов (шаблонов) проектирования, помогут вам понять, почему следует использовать именно этот каркас web-приложения, оценить его слабые и сильные стороны. Так же вы получите ответ, почему так сильно изменился Laravel 4 по сравнению с Laravel 3.
Для тех, кто все же решил изучить теорию, прежде чем приступить к практике, советую: запаситесь терпением.
После прочтения статьи не останавливайтесь на достигнутом, в сети много ресурсов, где можно почерпнуть нужную информацию по паттернам. Поверьте, зная, что такое паттерны, их конкретные реализации и как их использовать, можно добиться намного большего, чем оставив эту тему за пределами багажа своих знаний…
Определения
Паттерны это не так сложно как кажется
Если Вы спокойно и уверенно ориентируетесь в паттернах и парадигмах, то смело можете пропускать эту часть статьи. Но если, читая определения, Вы чувствуете, что это просто набор слов, то не поленитесь прочитать представленный ниже материал. Я надеюсь, он поможет вам разобраться в этой не очень простой для многих программистов теме и начать использовать паттерны в своей работе.
На самом деле паттерны не так сложны для понимания, как кажется на первый взгляд. Давайте проиллюстрируем их примерами, все сразу станет намного понятнее.
Итак, представьте, что вам необходимо разработать сложное приложение представлявшее каркас диалога и передачи данных между людьми, абстрактными Васей и Петей. Вначале мы рассмотрим простую программу того как Вася и Петя будут общаться между собой и производить обмен информацией:
Теперь разобьём эту программу на отдельные части:
У нас получился алгоритм действий для встречи и обмена диска на деньги между двумя индивидуумами.
Теперь разбиваем алгоритм на составляющие так:
Если же мы решим разработать универсальную программу для взаимодействия двух человек, то нам будет недостаточно такого куцего описания. Точнее нам к архитектурному паттерну понадобиться добавить паттерны, которые расширят описание реализации взаимодействия всех частей архитектурного паттерна.
Давайте попробуем составить схему таких паттернов самостоятельно:
В итоге у нас получилась своя схема паттернов.
Теперь, если мы опишем, как конкретно взаимодействуют наши паттерны между собой — то получим рабочие паттерны. Причем паттерны будут достаточно универсальными, чтобы на их основе писать приложения не только для общения людей, но и для общения инопланетян.
Если на основе наших паттернов написать приложение — получим каркас приложения для реализации общения, причем этот каркас можно будет очень легко модифицировать, так как он имеет очень детальную, хорошо продуманную и описанную структуру. Так же на основании нашего каркаса любой разработчик сможет легко написать собственное приложение для общения людей или компьютеров, или даже инопланетян. Ведь ему не нужно будет вникать в тонкости реализации взаимодействия компонентов нашего каркаса, ему будет достаточно знать общую структуру паттернов — архитектуру каркаса приложения, для того, чтобы составить свои правила общения, обмена данными, проверки условий и действий.
Паттерны бывают разными
Давайте теперь немного углубим наши знания. Дело в том, что паттерны бывают не только архитектурными, на самом деле у паттернов есть несколько классификаций.
Классификация по масштабу
Самая часто используемая классификация — это классификация по масштабу. Чаще всего она применяется для паттернов проектирования и делится на три слоя по детализации:
Классификация по стилю
Классификация по применению
Программистам редко приходится сталкиваться с данным классом паттернов, но все же стоит о нем упомянуть, чтобы иметь хотя бы общее представление. Это самый высокоуровневый класс паттернов. В него входят целые классы паттернов. Например:
И многие другие. Но я надеюсь их уже не нужно расписывать, вы вполне теперь способны продолжить этот список и без моих подсказок.
Заключение
Какие преимущества дают нам паттерны? Отвечу на этот вопрос, цитируя John Vlissides ( Влиссидес):
Паттерны суммируют опыт множества разработчиков и экспертов, делая его доступным рядовым разработчикам.
Именование паттернов позволяют создать своего рода словарь, с помощью которого разработчики могут понять друг друга намного лучше.
Если в документации к системе указано, на основе каких паттернов она построена, это позволяет быстрее понять структуру системы.
Правильно подобранные паттерны проектирования позволяют сделать программную систему более гибкой, ее легче поддерживать и модифицировать, а код такой системы в большей степени соответствует концепции повторного использования.
Для тех, кого заинтересовали паттерны, советую найти и почитать книги:
Статистика: Символов — 9 119/7 861 без пробелов (8 947/7 711 без кода):, слов — 1 237
Руководство по Laravel 8 для начинающих: как создать своё первое приложение
В этом руководстве по Laravel для начинающих мы расскажем, как установить Laravel и создать своё первое приложение на нём. В этом руководстве мы простым языком объясним все необходимые понятия, чтобы вы могли легко изучить Laravel и лучше его понять.
Введение
Laravel – это элегантный, выразительный и гибкий PHP-фреймворк с упором на чистый код и скорость. Он позиционирует себя как «PHP-фреймворк для веб-мастеров». Это бесплатный PHP-фреймворк с открытым исходным кодом, созданный Тейлором Отвелом на основе архитектурной модели Model View Controller (MVC).
Создание веб-приложения с нуля может быть сложной задачей, особенно если вы новичок. Простое веб-приложение содержит различные маленькие и большие компоненты, и вам, возможно, надоест создавать эти компоненты каждый раз, когда вы разрабатываете приложение. Это скучный и повторяющийся процесс, и нет никакого смысла изобретать велосипед. Вот тогда вам на помощь и приходит фреймворк Laravel.
Фреймворк Laravel предоставляет различные PHP-библиотеки и вспомогательные функции. Он обеспечивает общие функции и логику, чтобы упростить и ускорить разработку, а также помочь вам сосредоточиться на более важных вещах.
Сначала придется уделить немного времени обучению, особенно если вы новичок и не имеете опыта работы с какими-либо веб-фреймворками. Но поверьте мне, если вы наловчитесь, вы не только полюбите, но и пристраститесь к Laravel. Этот фреймворк поддерживает творчество в разработке. Он использует слово «Веб-мастер», чтобы указать на креатив, скрытый в сердце разработчика. Результат — эффективное приложение с меньшим количеством строк и хорошо продуманным кодом.
Чтобы вам было легче изучить Laravel, я написал это руководство специально для неопытной аудитории. Так вам будет проще следовать этому руководству и изучать Laravel.
Что вы должны знать перед использованием этого руководства по Laravel?
Установка и настройка
Laravel предлагает различные способы установки на Windows или Mac. Лучший и самый простой способ установить Laravel – через Composer. Composer — это менеджер зависимостей для PHP, который вы можете установить на свой веб-сервер.
Требования для установки Laravel 8
Перед установкой Laravel на вашу локальную платформу (Localhost) вам необходимо установить следующие программы:
Пошаговая установка Laravel на локальном хосте:
Шаги для пользователей Mac:
Шаги для пользователей Windows:
В нашем примере выполняем:
Руководство по созданию простого CRUD-приложения для составления списка дел на Laravel
Лучший способ изучить программирование – практиковаться. Поэтому здесь мы будем изучать основы Laravel, разрабатывая простое веб-приложение, которое будет выполнять перечисленные ниже функции. В рамках этого руководства по Laravel:
Изучение структуры папок
Laravel — приложения следуют шаблону проектирования архитектуры MVC (Model-View-Controller).
После того как вы установили Composer и создали свое первое веб-приложение на основе Laravel, вы могли заметить папку приложения с разными файлами и папками внутри. Я знаю, если вы новичок, у вас может возникнуть много вопросов о том, для чего нужны эти папки и т. д. и т. п.
Давайте разберём некоторые из них
Пошаговое создание вашего первого приложения на Laravel
Создайте ваш проект
Если вы не создали свой проект в разделе установки, создайте его сейчас, выполнив следующую команду:
Настройте базу данных
Для нашего приложения нам понадобится база данных, поэтому лучше всего создать её в первую очередь. Laravel поддерживает четыре СУБД:
В этом файле вы найдете код, похожий на следующий:
Замените все шесть строк, приведенные выше на одну строку, указанную ниже, то есть измените значение db_connection на sqlite и удалите остальные строки db, как здесь:
Создайте аутентификацию
Есть два способа добавить Jetstream в ваше новое Laravel-приложение. Если вы еще не создали проект, добавьте флажок
для новой команды Laravel:
Jetstream в Laravel поддерживает два стека
Liveware или Inerta. Поскольку мы хотим, чтобы этот проект был простым, давайте воспользуемся Livewire и установим Jetstream с помощью следующей команды:
На данном этапе мы закончили с настройкой и можем приступать непосредственно к созданию приложения.
Миграции
Первый шаг в разработке любого приложения – это создание базы данных. Laravel предлагает отличный способ разработки таблиц и схемы базы данных, а также даёт возможность легко переносить их в разные системы, которые называются «Миграции».
Миграции используются, чтобы создавать, изменять, а также делиться схемой базы данных приложения. Они используются с конструктором схем Laravel, чтобы упростить создание схемы базы данных. В создании миграций для вашей базы данных есть много преимуществ. Вы сможете легко перестроить структуру своей базы данных, используя файлы миграции в производственной и любой другой системе.
Ничего страшного, если это объяснение показалось вам непонятным. Поверьте, скоро у вас всё получится. Просто читайте дальше.
Выполните следующую команду:
Вы найдёте только что созданную миграцию в папке /database/migrations.
Теперь давайте добавим еще два столбца в таблицу задач, отредактировав только что созданный файл миграции.
Теперь мы закончили с созданием схемы базы данных. Чтобы использовать эту схему для создания таблиц в базе данных, выполните следующую команду. Команда migrate обновит изменения, внесенные в схему, в базе данных.
Eloquent – это ORM (система объектно-реляционного отображения) для Laravel, которая позволяет свободно применять active-record для работы с базой данных. Каждая таблица базы данных может иметь соответствующую модель Eloquent. Модель Eloquent представляет объекты базы данных. Она может использоваться для запроса данных, а также для вставки и обновления данных в таблице. Итак, давайте с помощью команды make: model создадим модель для нашей таблицы задач.
Эта команда создаст модель задачи в папке приложения, как показано ниже.
Отношение «один-ко-многим»
Отношения используются для соединения таблиц. Eloquent даёт возможность связать свои модели через отношения Eloquent. Отношение «один ко многим» означает, что одна модель владеет несколькими объемами другой модели. В нашем примере: у одного пользователя может быть много задач, поэтому между таблицей пользователей и таблицей задач существует связь «один ко многим». Отношения Eloquent очень легко определить и использовать. И преимущество заключается в том, что вам вообще не нужно запускать запросы. Eloquent свяжет модели между собой, поэтому вам придется использовать только функции.
Давайте отредактируем модель задачи и модель пользователя, чтобы создать отношения Eloquent.
Модель задачи (файл task.php находится в app/task.php):
Модель пользователя (файл user.php находится в app/user.php):
Команда Tinker в Artisan (необязательно)
В Laravel существует интерфейс командной строки, известный как Artisan. Artisan содержит различные команды, и среди них – Tinker, которую мы собираемся обсудить. Tinker позволяет вам взаимодействовать со всем вашим Laravel- приложением через окно консоли без необходимости доступа к веб-интерфейсу. Основным преимуществом Tinker является то, что вы можете тестировать отношения, отлаживать данные и получать доступ к Eloquent ORM, задачам, тестам, событиям и т. д. Поэтому мы также будем использовать команду Tinker в нашем руководстве по Laravel. Допустим, вы зарегистрировались в приложении и создали две задачи. Теперь вы проверяете эти задачи прямо в окне консоли, как показано ниже:
Tinker напрямую обращается к базе данных, так что это отличный инструмент для тестирования функций, а также данных.
Контроллеры
Контроллеры используются для распределения трафика между представлениями и моделями. Они могут сгруппировать несколько логических схем обработки запросов в один класс. Таким образом, как правило, они получают весь запрос и, исходя из своей логики, перенаправляют или возвращают соответствующие данные. В нашем примере мы уже подходим к интерфейсу, поэтому мы должны создать контроллеры, через которые сможем обрабатывать запросы, поступающие в наше приложение. Выполните следующую команду, чтобы создать контроллер для задач:
Таким образом, будет создан TasksController, который вы сможете найти в папке app / Http / Controllers.
Маршрутизация
Маршрутизация означает принятие запроса и его перенаправление к соответствующей функции. Нашему приложению понадобится пять маршрутов, которые будут выполнять следующие действия:
Laravel Jetstream добавляет вход и регистрацию, поэтому теперь нам нужно позаботиться только о трех маршрутах.
Laravel предоставляет различные файлы маршрутов внутри папки / routes для разных случаев использования. Например, настройка маршрутизации для API будет находиться в файле « /routes/api.php », а настройка маршрутизации для нашего веб-приложения будет находиться в «/routes/web.php».
Здесь мы внесли два изменения:
Представления – шаблоны Blade
Теперь в папке / resources / views создайте файлы add.blade.php и edit.blade.php с разметкой, приведенной ниже.
В файле dashboard.blade.php также замените весь код на тот, который приведен выше. Представления мы отредактируем позже, после определения функций нашего контроллера с помощью привязки модели к маршруту.
Привязка модели к маршруту (Route-Model Binding)
В Laravel есть множество удивительных функций, которые делают веб-разработку простой, чистой и менее трудоемкой. Одна из наиболее заметных функций подобного рода – привязка модели к маршруту (Route-Model Binding). Это механизм для внедрения экземпляра модели в ваши маршруты. Это значит, вы можете передавать объект модели в маршруты, а также в представления по маршрутам. Эта функция поможет вам легко получить значения объекта в представлении. Ничего страшного, если это объяснение кажется непонятным. Со временем вы все поймёте.
Теперь давайте добавим в TasksController.php функции, обрабатывающие указанные выше маршруты. Они должны выглядеть так, как показано ниже:
Примечание : Не забудьте добавить «use App \ Models \ Task;» иначе вы получите сообщение об ошибке «Класс не найден».
Редактируем представления
Теперь функции контроллера настроены и возвращают соответствующие представления с прикрепленными объектами модели. Итак, теперь нужно отредактировать наши представления, чтобы они, если нужно, показывали форму и необходимые данные, используя объекты модели, переданные по маршрутам.
Страница, отображающая все задачи
Откройте файл dashboard.blade.php и отредактируйте его следующим образом:
Механизм шаблонов Blade позволяет нам использовать PHP внутри HTML, не заключая его в « ».
Страница, добавляющая новую задачу
Откройте файл add.blade.php и отредактируйте его следующим образом:
<
Страница, редактирующая задачу
Откройте файл edit.blade.php и отредактируйте его, как показано ниже:
После редактирования этого представления мы собираем все части воедино, так что теперь сможем протестировать своё приложение.
Сначала зарегистрируйтесь, затем войдите в систему, а потом проверьте, можете ли вы создать задачу, отредактировать задачу и удалить задачу.
Запускаем проект на Localhost
Чтобы запустить проект, запустите в окне терминала команду php artisan serve. Убедитесь, что вы находитесь в корне вашего приложения в терминале.
Что делать с этим проектом дальше:
Существует множество вещей, которые можно добавить в этот проект, например:
Заключение
В этом длинном руководстве по Laravel мы узнали, как установить Laravel, настроить базу данных, а также такие основные вещи, как маршруты, модели, представления и контроллеры, а также создали ваше первое приложение на Laravel — приложение для составления списка задач.
Надеюсь, что это руководство по Laravel помогло вам понять основы Laravel, а также мотивировало вас учиться дальше. Пожалуйста, поделитесь своим мнением о Laravel и об этом руководстве. А также вы можете делиться в комментариях к этой статье вашими вопросами и проблемами. Будем рады вам помочь. Спасибо.
Пожалуйста, оставьте свои отзывы по текущей теме материала. За комментарии, подписки, дизлайки, отклики, лайки низкий вам поклон!