Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Добрый день. Изучаю laravel 5, до этого с фреймворками дело не имел. Занимался собственными самописнымы штуками + работал счужими такими же самописными. Хочется лучше понять, что куда разложить. В уроках в основном показываются базовые вещи, где контроллер поулчает данные из БД и передает их во вьюер, а тот делает голую обработку без условий и рендерит шаблон. Все это классно, но реальные проекты далеки от базовых-обучалок. Много кода, много логики. И куда это все поместить, пока непонятно. Поделитесь пожалуйста опытом организации кода во фреймворке.
К примеру, интересуют такие вещи:
- Контроллер должен быть тонким. Модель работает с БД. Представление отрисовывает по данным html код. Встает вопрос - когда контроллер получает какие-то данные, их требуется еще сложить\удалить\поделить\получить какие-то промежуточные html-блоки с последующей вставкой в основной вид. Где организовывать обработку всей этой логики? На сколько контроллер может быть "толстым"?
- Есть набор своих наработанных функций за все это время. Как их можно подключить в проект. Прошу, назовите что это будет в ларавел, дальше разберусь по документации))
PS. И если можно, пару слов о сервис-провайдерах. Прям два слова, которые объяснят что это и для чего)) До этого не имел дела с таким понятием.
Спасибо
Не в сети
Так же, куда вынести класс, который получает набор полей, по которым отрисовывает html-блок (столбцы фильтров) и отдает их вызывающему методу. так же класс имеет свой файл конфига.
Не в сети
Блин, поделится кто-то опытом?)) Как же самое отзывчевое русское сообщество, что и подкупило в изучение сего фреймворка?
Не в сети
>> Есть набор своих наработанных функций за все это время. Как их можно подключить в проект. Прошу, назовите что это будет в ларавел, дальше разберусь по документации))
Есть несколько вариантов
1) Стандартный компоузер пакет
2) Пакет для Ларавеля https://laravel.ru/docs/v5/packages
3) Стандартный хелпер https://laravel.ru/docs/v5/helpers хотя тут нет инфо как добавить свой хелпер, но если по коду посмотришь найдешь. Или напиши, я посмотрю в одном из своих проектов
4) Класс со статическими методами
Изменено DBR (11.10.2016 03:58:17)
Не в сети
Не в сети
>> Контроллер должен быть тонким.
Всю логику выносишь в пакеты, или в модули, или в отдельные классы. В контролере только вызов методов, присваивание переменных и передача во вьюхи.
Поначалу это кажется неудобным и совершенно не нужным, но потом привыкаешь и начинаешь видеть пользу.
Хотя наверно про всю логику это чересчур. Часть можно оставить в контроллере, когда а) кода мала б) он точно нигде больше не будет использоваться
Не в сети
>> Так же, куда вынести класс, который получает набор полей
Создай App/Renders/* и туда выноси свой класси конфиг для него. Можно под каждый класс отдельную папку. Можно конфиги хранить в отдельной папке.
В Ларавеле нет той строгости архитектуры, как в некоторых других фреймворках. Делаешь так как тебе удобнее
Не в сети
DBR, спасибо!
Не в сети
бы предложил на стадии разработки писать всё в контроллер, а перед релизом выделить время и распихать уже по полочкам.
так как в процессе проектирования проектируется отнюдь не 100% архитектуры, и даже не 60, в противоположность состоянию на релиз.
Не в сети
>> Контроллер должен быть тонким.
Всю логику выносишь в пакеты, или в модули, или в отдельные классы. В контролере только вызов методов, присваивание переменных и передача во вьюхи.
Поначалу это кажется неудобным и совершенно не нужным, но потом привыкаешь и начинаешь видеть пользу.
Хотя наверно про всю логику это чересчур. Часть можно оставить в контроллере, когда а) кода мала б) он точно нигде больше не будет использоваться
А то, что многие пишут про шаблон проектирвоания репозиторий?
Не в сети
бы предложил на стадии разработки писать всё в контроллер, а перед релизом выделить время и распихать уже по полочкам.
так как в процессе проектирования проектируется отнюдь не 100% архитектуры, и даже не 60, в противоположность состоянию на релиз.
Имеет место быть, конечно. Даже в большом проекте, время от времени потребуется уделить время на перестановку кода. Но хочется, хотябы на этапе проектирования базовые вещи запихнуть туда, где они и должны быть)
Не в сети
hzone пишет:бы предложил на стадии разработки писать всё в контроллер, а перед релизом выделить время и распихать уже по полочкам.
так как в процессе проектирования проектируется отнюдь не 100% архитектуры, и даже не 60, в противоположность состоянию на релиз.Имеет место быть, конечно. Даже в большом проекте, время от времени потребуется уделить время на перестановку кода. Но хочется, хотябы на этапе проектирования базовые вещи запихнуть туда, где они и должны быть)
В каждом следующем Проекте всегда учитываются подводные камни предыдущего (если вовремя вспомнил )
Но при этом всегда будет бесконечно не малый %% изменений в процессе реализации Проекта.
Не в сети
Чтобы по Views не было много логики, можно использовать Presenter https://github.com/laracasts/Presenter
Страницы 1