Есть два типа новичков, изучающих Laravel: один — послушно заливать программу в MVC-фреймворк, в результате чего получаются аномально большие контроллеры и модели, которые в дальнейшем будет сложно поддерживать, другой — часто не знать, какой класс для написания программы. В конце концов, традиционный PHP — это страница и файл. В этой статье выбирается наиболее подходящая структура среднего и крупного проекта для Laravel, которую легко поддерживать, легко расширять, легко использовать повторно и легко тестировать.
Контроллер слишком толстый
ROR затронут, новички часто думают, что архитектура MVC является моделью, вид, контроллер:
- Модель — это база данных.
- Контроллер отвечает за связь с HTTP и за вызов модели и представления.
- Представление — это HTML.
Если по этому определению, то где должны быть написаны следующие требования?
- Отправить письмо, использовать внешний API.
- Логика написана на PHP.
- Преобразуйте формат отображения по мере необходимости.
- Нужно ли отображать некоторые данные по мере необходимости.
- Отображение различных данных по мере необходимости.
Среди них 1 и 2 относятся к бизнес-логике, а 3, 4 и 5 — к логике отображения.Согласно определению MVC обычными людьми, модель — это база данных, а представление — HTML.Вышеуказанные требования не могут быть прописано в модели и представлении Записано в контроллере.
Поэтому новички начинают писать в контроллере большое количество программ, что делает контроллер гипертрофированным и сложным в обслуживании.
Модель слишком толстая
Так как неудобно поддерживать логику в контроллере, можно просто написать логику в модели?
При перемещении логики из контроллера в модель, хотя контроллер становится тоньше, модель становится толще.Модель изначально представляла собой базу данных, но теперь она должна нести бизнес-логику и отображать логику, а результат еще хуже.
Модель означает базу данных? Думайте об этом как о классе Eloquent, логика базы данных должна быть написана в репозитории, поэтому в Laravel 5 больше нет каталога моделей, а класс Eloquent просто помещается в корневой каталог приложения.
Структура среднего и крупного проекта
Итак, как мы должны написать это? Не ограничивайте наше мышление MVC:
Model: Только как класс Eloquent.
Repository: Вспомогательная модель, обработка логики базы данных, а затем внедрение в сервис.
Service: помощь контроллеру, обработка бизнес-логики, а затем внедрение ее в контроллер.
Controller: получать HTTP-запросы и вызывать другие службы.
Presenter: Обработать логику отображения и внедрить ее в представление.
View: Используйте лезвие для привязки данных к HTML.
Среди них синий — это исходный MVC, а фиолетовый — в центре внимания этой статьи: режим репозитория, режим службы и режим докладчика.
Стрелки указывают направление внедрения зависимости объекта.
Мы можем обнаружить, что архитектура MVC все еще существует благодаря принципу единой ответственности SOLID и принципу инверсии зависимостей:
- Мы отделяем логику базы данных от модели, поддерживаем модель репозиторием и внедряем зависимости модели в репозиторий.
- Мы отделяемся от контроллера Business Logic, помогая контроллеру обслуживания, впрыск в зависимости от службы в контроллер.
- Мы отделяем логику отображения от представления, помогаем представлению докладчиком и внедряем зависимость докладчика в представление.
создать каталог
Создайте каталоги Repositories, Services и Presenters в каталоге приложения.
Не бойтесь создавать другие каталоги за пределами каталога Laravel по умолчанию.Согласно принципу единой ответственности SOLID, чем больше функций у класса, тем больше у него ответственности, поэтому тем больше он нарушает принцип единой ответственности, поэтому вам следует разделить программу на более мелкие части, каждая часть имеет свою собственную функцию, а не функцию класса, которая является так называемой универсальной категорией, поэтому весь проект должен состоять не только из трех частей MVC, позвольте перейти к созданию соответствующего каталога в соответствии с вашими потребности, и поместите соответствующий класс в этот каталог, если у нашего класса есть пространство имен, помогающее нам его классифицировать.Repository
Из-за нехватки места репозиторий будет обсуждаться в отдельной статье, пожалуйста, обратитесь к тому, как использоватьRepositoryмодель?Service
Из-за нехватки места сервис обсуждается в отдельной статье, пожалуйста, обратитесь к тому, как его использовать.Сервисный режим?Presenter
Из-за нехватки места презентер будет обсуждаться в отдельной статье, пожалуйста, обратитесь к тому, как его использовать.Режим докладчика?модульный тест
Поскольку все зависимые объекты модели, представления и контроллера были дизассемблированы и используется внедрение зависимостей, каждую часть можно протестировать отдельно.Если вы хотите протестировать службу, вы можете смоделировать репозиторий или добавить другие службы. высмеивать.
Presenter также может запускать модульные тесты в одиночку и имитировать другие службы. Нет необходимости запускать приемочные тесты для проверки логики отображения.Conclusion
Архитектура, упомянутая в этой статье, — это только начало.Вы можете добавить больше каталогов и классов в соответствии с реальными потребностями.Когда вы обнаружите, что ваш MVC нарушает принцип SOLID, вы можете смело дизассемблировать и рефакторить класс из MVC, а затем следовать следующему методы:- Создайте новый класс или интерфейс.
- Внедрение зависимостей зависимых объектов в класс.
- Выполнять свои обязанности в классе.
- Вставьте класс или интерфейс в контроллер или представление.
Наконец, с помощью модульного тестирования проверьте, соответствует ли реорганизованная архитектура исходным требованиям.