Как правильно организовать код в php-фреймворке?

Question

[Артем Кисленко]

Здравствуйте, вопрос от новичка.
Как правильно организовать код, чтобы конроллеры и модели не разрастались до огромных простыней.

Сейчас работаю над проектом, написанным на Laravel, там куча всего, но главная проблема, что есть длинные контроллеры, которые отвечают за много всего. Как принято в php вообще делать - что в контроллере мы делаем запросы к базе, используя ORM или конструктор запросов, агрегируем данные и выплевываем, или все нужно выносить в модели, но тогда модели будут просто огромными, что делать?

Answer 1

[Евгений]

Учиться, учиться и еще раз учиться, как завещал дедушка Ленин.
Не видя сам код и структуру проекта, тут трудно что-либо советовать. Почитайте "Чистый код" Боба Мартина, особенно про принцип единой ответственности. Если метод вашего класса не помещается на мониторе компьютера - его необходимо переписать. Ну и все в таком духе. Главное не гнаться за чистотой кода ради самой чистоты. Все к чему призывает дядя Боб, это писать читаемый, поддерживаемый код, который после Вас смогут читать и поддерживать другие разработчики.

И еще важный момент, закрепите правила разработки на уровне команды. Т.е. что бы все писали одинаково. Структура проекта должна быть четкой и понятной. Мы в своей команде такие правила обозначили (они конечно же пересматриваются, обсуждаются) и теперь команда из 6 разработчиков легко ориентируется в коде enterprise монстра с 6 летней историей, и с over 5000 классов на борту, и даже умудряется его улучшать.

По поводу контроллеров: я лично не знаком с философией Laravel, сам разрабатываю на Java и мой framework - Spring. У меня философия на счет контроллеров такая - контроллер является посредником между front и back end-ами. Никакой логики контроллер в себе не содержит, от слова "совсем". Вся логика вынесена в фасад, который в свою очередь может включать в себя кучу сервисов. Сервисы (по-возможности) разрабатываются с учетом принципа единой ответственности. Сервисы содержат в себе всю бизнес-логику приложения.

Comments

[Артем Кисленко]

> И еще важный момент, закрепите правила разработки на уровне команды.

Если не затруднит, не могли бы вы привести примеры таких правил?

[Евгений]

Артем Кисленко: Ну например, что логики в контроллерах быть не должно. Каждый сервис - singleton. Ну и правила оформления коды, которые Code Conventions.

[Евгений]

OnYourLips: согласен. Просто в Spring задачи, Вами описанные, в 99% случаев выполняются средствами самого фреймворка. Если прям что-то очень важное нужно обработать, тогда да, берем request и препарируем как надо.

Answer 2

[Максим Алёхин]

Как принято в php вообще делать - что в контроллере мы делаем запросы к базе, используя ORM или конструктор запросов, агрегируем данные и выплевываем, или все нужно выносить в модели, но тогда модели будут просто огромными, что делать?

Принято как раз наоборот - вся логика БД должна быть в моделях, а что бы модели не были огромными, разбивайте логику на несколько моделей если используются разные таблицы, ту часть которая конкретна только для конкретной страницы оставляйте в контроллере, используйте весь доступный функционал фреймворка - хелперы, формы, библиотеки и т.д.

У нас как раз Ваша проблема с проектом, когда мы пришли и увидели код, там вся логика была исключительно в контроллерах. Ощущение что предыдущие программисты про ничего другое вообще не слышали.

Comments

[Артем Кисленко]

А это проблему вы будете решать или постепенно шаг за шагом все как-нибудь само перепишится?

[Максим Алёхин]

Само не перепишется, но и решать комплексно тоже задачи нет - компании нужно двигаться вперед. Поэтому когда появляется задача которая касается такого старого контроллера, то он заодно и переписывается, рефакторится.

Answer 3

[trevoga_su]

контроллер авторизации, моя разработка полностью

надеюсь, все понятно будет

Comments

[Артем Кисленко]

Да, спасибо, примерно так и я представлял себе контроллер! )