Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Здравствуйте, такой вопрос есть ли какая то универсальная структура проекта, которая будет хорошо расширятся и дополнятся?
Желательно с аргументами почему именно ваш вариант лучше)
Не в сети
Универсальной структуры нет, иначе бы кроме неё ничего не существовало. Но общие принципы назвать, наверное, можно.
Распространенное правило - держать контроллеры тонкими, т.е. с минимум кода, функционал писать в классах, каждый из которых обладает узкой специализацией (если на вопрос "что делает этот класс" в ответе присутствует союз "и" два или три раза, то пора рефакторить). Приложение из таких классов удобно покрывать юнит-тестами, в случае добавления нового функционала вы добавляете новые классы и тесты, слабо изменяя предыдущие и сводите появление новых багов к минимуму.
Если вы планируете использовать тесты (а для хороших больших приложений они все-таки необходимы, хотя я лично так и не могу себя заставить их писать), постарайтесь не юзать фасады и оператор new - используйте DI в виде передачи параметров в конструктор и App::make().
Работу с моделями по возможности (но без фанатизма) выносите в репозитории. Т.е. контроллер вызывает метод репозитория, в котором вызывается модель (или несколько) с нужными параметрами и, если надо, результат кэшируется. Об этом можно прочитать, например, в "From apprentice to artisan" Тейлора.
Интересный метод избавления контроллера от кода предложил Джеффри Вей в своем цикле "Commands and Domain Events": https://laracasts.com/series/commands-and-domain-events , https://laracasts.com/lessons/introduci … -commander. Также в рамках этой парадигмы он пишет пример соцсеточки Larabook - https://laracasts.com/series/build-a-la … om-scratch .
Также многие рекомендуют разделять классы в приложении не по функциональности низкого уровня (в этой папке у нас контроллеры, в этой модели, тут правила валидаторов), а по логическому разделению на более высоком уровне (в этой папке у нас все, что относится к пользователям, в этой - все, что к постам, тут - к заказам, тут - к счетам, а это - общее). Пример такой архитектуры можно видеть здесь: https://github.com/Siliconsoul/FusionIn … FI/Modules . Хотя папка Modules имхо лишняя, проще все в коренном неймспейсе размещать, т.е. в данном случае FI.
Я сделал пакет, который генерит подобные модули внутри неймспейса, чтобы руками каждый раз не создавать кучу папок и прописывать все в сервис-провайдере: https://github.com/slider23/laravel-modulator
Но польза от такого разделения кода немного сомнительна. Например, роуты неудобно держать по модулям, проще все в одном файле. Но если они в разных файлах, то можно переносить модули из приложения в приложение. В общем, все это субъективно.
Также полезным времяпрепровождением будет чтение и конспектирование http://refactoring.guru
Не в сети
Спасибо) Почему не юзать фасады и new, я читал что фасады плохо только потому что они расширяют сферу деятельности своего класса, тем самым вносят путаницу и не до понимания. Ну а DI это сила.
Хотелось бы еще услышать мнения.
Не в сети
Мастер 
- Почему не юзать фасады и new
new по той же причине, по которой существует IoC — new требует от тебя фиксированного указания класса и ты не можешь его заменить в тестах на другое (т.е. если создаёшь класс для работы с БД как new User, то в тестах тебе придётся делать тестовую же БД, зависимости, потом всё чистить и так далее).
А фасадов, на мой взгляд, стоит избегать из-за того, что за ними не видно, на какой реальный класс/объект идут вызовы. Яркий пример — Eloquent, где вызывая Model::whereFoo('bar') ты на самом деле создаёшь новый экземпляр Model, затем получаешь экземпляр запроса (Query), затем вызываешь whereFoo(), но на самом деле он транслируется в where('foo')… Легко ли проследить этот путь в уме, особенно если ты новичок?
И, кстати, если использовать макросы — то тут вообще концов не найти, так как регистрировать их можно в любом месте кода и выполнять они могут что угодно, хоть HTML выводить.
- они расширяют сферу деятельности своего класса, тем самым вносят путаницу и не до понимания
На самом деле основная проблема не в этом, а в том, что я описал выше. Область ответственности класса — это старая проблема ООП, тут однозначного ответа нет (всё зависит от задачи проекта, его масштабов, да и предпочтений самого разработчика/ов). А вот с макаронами из динамических вызовов всё довольно однозначно.
Не в сети
Благодарю за ответ ) Почитал о репозиториях, кода конечно плодится тьма))
Не в сети
Может у вас есть какой то проект на ларавеле желательно 4.2 ) в открытом виде, чтоб посмотреть че да как и куда. Буду признателен.
Не в сети
Можете посмотреть https://github.com/LaravelRUS/laravel.su , это пробный камушек на роль нового laravel.ru, незавершенный, но запустить можно.
Пример репозитория: https://github.com/LaravelRUS/laravel.s … stRepo.php .
Базовый репозиторий, от которого наследуются остальные: https://github.com/LaravelRUS/laravel.s … sitory.php
Контроллер: https://github.com/LaravelRUS/laravel.s … roller.php
Для валидации используется пакет laracasts/Validation (валидаторы лежат в папке Forms).
Не в сети
Спасибо, интересная структура )
Не в сети
За рефакторинг отдельное спасибо) инфа полезная
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)