Каким бы я хотел видеть свой первый проект на Symfony

Вот уже полтора года я использую Symfony 2 для разработки web-приложений. За это время я трижды начинал новый проект, еще в трех проектах работал с унаследованным кодом, а также провел ревью около 15 тестовых заданий на знание фреймворка.

Наверное, было бы здорово иметь возможность вернуться на полтора года назад и дать себе несколько советов перед стартом своего первого проекта. Увы, это невозможно. Но может быть, мои советы могут пригодятся другим начинающим разработчикам на Symfony?



Соблюдай кодстайл и конвенции по наименованию

Я не стану в тысячный раз говорить о важности кодстайла, но большинство начинающих девелоперов его не соблюдают.

К счастью эту проблему легко исправить. Современные IDE могут автоматически форматировать код по выбранным правилам. Сейчас я использую PHPStorm. Тут есть и предустановленные настройки для Symfony, и автоматическое добавление оператора use, и еще много вкусностей.

Если говорить о стандартах кодирования, нельзя не упомянуть о PHP CS Fixer от Fabien Potencier. PHP CS Fixer станет для тебя обязательным инструментом через некоторое время.

Небольшое лирическое отступление. В социологии, существует Теория разбитых окон, которая говорит о том, что игнорирование общепринятых правил одними людьми провоцирует других людей так же игнорировать эти и другие правила. Исправляй ошибки кодстайла в проекте, не оставляйте “разбитых окон” в своем коде.

Не делай толстых контроллеров

Толстые тупые уродливые контроллеры (ТТУК), вторая по популярности ошибка, которая встречается в коде начинающего девелопера. Про толстые контроллеры написано немало. Если в двух словах, то контроллеры не являются переиспользуемыми программными модулями в общем случае. Поэтому не стоит тут держать бизнес логику. Логика в контроллерах приводит к нарушению принципе DRY и провоцирует на копипаст. Выноси бизнес логику в слой сервисов, в модель, куда угодно. Не стесняйся создавать новый класс, сервис, метод, стесняйся делать ТТУКи.

Не делай сервисы зависимые от контейнера

Лучше всего забудь, что такая возможность вообще существует. В момент, когда ты создашь зависимый от контейнера сервис, ты перестанешь контролировать, что в нем происходит. А если тебе хочется внедрить в сервис весь контейнер, только потому что он “распухает” от зависимостей, то, скорее всего, что у тебя проблемы с архитектурой. Контейнер в сервисе будет провоцировать тебя на нарушение Single responsibility principle и уж никак не будет способствовать созданию правильного дизайна. Container aware сервисы будет тяжело тестировать. А если заведешь себе иерархию на основе такого класса, то это еще и будет тяжело отрефакторить.

Посмотри на Service Container с другой стороны. Это в первую очередь инструмент для конфигурации зависимостей, а не место откуда ты можешь дернуть любой сервис. Не используй контейнер в других классах, кроме контроллеров. А еще лучше приучи себя и контроллеры делать сервисами. Тебе же самому будет легче понимать и контролировать, то что происходит в твоем коде.

Пиши код максимально просто

Во-первых, перестань делать лишние интерфейсы. Не вводи интерфейс лишь для того, чтобы не делать зависимость от конкретного класса. Твоя единственная конкретная реализация интерфейса, возможно, так и будет жить в проекте годами. Не бойся делать зависимости на конкретный класс. Ты легко сможешь отрефакторить код и добавить интерфейс тогда, когда увидишь в нем необходимость.

Во-вторых, делай публичный API классов как можно проще. Другими словами, не стоит делать публичных методов у класса, которые ты не будешь использовать прямо сейчас.

В-третьих, методы и свойства, которые не являются публичным API класса делай приватными по дефолту. Ты всегда сможешь изменить область видимости, если появится необходимость перекрыть метод или свойство. Но когда другой программист будет читать твой код, он будет на сто процентов уверен, что этот метод не используется нигде больше.

В-четвертых, не стоит имплементить сейчас то, что будет использоваться завтра. Практика показывает, что это призрачное завтра может никогда и не наступить. Да, ты никогда не сможешь точно сказать, как изменятся требования к проекту. Так зачем же усложнять проект сейчас? Зачем тебе делать лишнюю работу?

Ну и, в-пятых, не включай в проект целые бандлы, ради одной маленькой фичи. Например, тебе же не нужен FOSRestBundle, чтобы в одном из контроллеров вернуть JSON.

Не злоупотребляй комментариями

Не комментируй то, что очевидно. Не добавляй комментарии к методам, только потому что твоя IDE умеет это делать автоматически. Если ты удачно выбрал названия классов, методов, переменных и свойств у тебя вообще никогда не должно возникнуть желание добавить комментарий в код.

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

Хорошо разберись в том, как работает Doctrine

Чаще всего твои собственные ошибки, а не ORM будут причиной медленной работы приложения с БД. Правильно определяй тип и направленность отношений между сущностями. Не злоупотребляй наследованием в сущностях. Постоянно заглядывай в профайлер, чтобы контролировать как быстро работает слой доступа к данным и какие запросы создает ORM. Избегай вложенных транзакций. Вызывай flush только в контроллере. Прочти еще раз документацию по Doctrine, хотя бы по диагонали.

Используй все возможности Twig

Twig очень хороший шаблонизатор. Со временем ты это поймешь. Его очень легко расширять при необходимости. Но и того, что есть в стандартной поставке с головой хватит, чтобы перестать дублировать код в шаблонах. Перечитай еще раз документацию, там немного. И пользуйся всеми возможностями этого инструмента.

Грамотно пользуйся исключениями

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

Не делай конфиги громоздкими

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

Почаще обновляй зависимости в проекте

Используй стабильные версии бандлов, если есть такая возможность. А если нет, то обновляй зависимости как можно чаще. Ошибки лучше всего исправлять по мере их появления. Когда ты насобираешь много обновлений, то и устранить все проблемы несовместимости, будет намного сложнее.

Пиши тесты

Пиши приемочные тесты на Behat с первого дня проекта. Потом будет тяжелее покрыть весь функционал. Создание тестового окружения требует определенного времени. Но на начальных этапах это время будет размазываться между другими задачами. А в дальнейшем эти тесты будут часто тебя выручать.

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

Ну, а самый главный совет, который я бы хотел себе дать: “Не бойся делать ошибки, но стремись работать в команде с более опытными разработчиками, которые тебе на них укажут. Ну, а если у тебя сейчас нет такой возможности в коммерческом проекте, ищи таких людей в OSS.”

Немного ссылок:
Поделиться публикацией

Комментарии 86

    +1
    Спасибо за статью. Болью в сердце отзывается призыв писать тесты.

    Если можно — вопрос: чего начать переход в Symfony 1.4 на Symfony 2? Не в конкретном проекте, а в разработке в целом?
      0
      Попробуйте поработать над связкой twig + controller в одном бандле. Потом сервисы.
        0
        Бандл — это аналог плагина в Symfony 1?
          0
          Это может быть плагин, а может быть целый сайт.
          Какая структура будет более удобная для вас, то и будет :)
          Мы дробим на бандлы, но бывает много контроллеров в одном бандле.
            0
            Думаю, воспользуюсь вашим советом, спасибо.
              0
              Да, кому как больше нравится. В RadBundle к примеру используется общий неймспейс App rad.knplabs.com/, что как-по мне удобнее для небольших приложений. По идее о правильном распределнии функционала говорит тот факт, что Вы сможете удалить бандл потеряв часть функционала, но не потеряв работосопосбности остальной части приложения. Но у Вас всегда будет какой-нибудь CoreBundle, который Вы не сможете удалить.
          +2
          Да, в общем-то, сложный вопрос. Я то не знаю, другие Ваши скилы, кроме symfony 1.4 :) Возможно, придется привыкать к неймспейсам или другим особенностям 5.3, 5.4.

          Но в любом случае, я бы советовал начать с документации в таком порядке:

          1. Qick tour symfony.com/doc/current/quick_tour
          2. The book symfony.com/doc/current/book/index.html
          3. Cookbook symfony.com/doc/current/cookbook/index.html

          Советую также посмотреть скринкасты на knpuniversity.com/ и подписаться на Twitter топ-контрибьютеров Symfony github.com/symfony/symfony/contributors
            0
            Спасибо за ссылки. До нового года начинал просматривать информацию по Symfony 2, но сессия, прочее не дали. Тогда не было ничего уровня Jobeet для Symfony 1.4 — ничего не изменилось?
          0
          Расскажите, пожалуйста, как вы пришли к решению переходить с 1.4 на 2? Есть ли серьезные аргументы в пользу этого перехода (особенно с точки зрения бизнеса, а не разработчика)?
            0
            Мне только один небольшой проект довелось переводить с 1.4 на 2. Да и то, это было желание самого заказчика, который, к слову, тоже был программистом.

            А если насчет аргументов, то самый серьезный, это то что 1.4 не поддерживается, если не ошибаюсь, примерно с сентября 2012.
              0
              Да, соглашусь, 1.4 уже не поддерживается.

              Ну и мне необходим следующий шаг, я застрял на php 5.2 и даже не пробовал много нового в деле.

              С точки зрения бизнеса — аргументов нет. Проект и дальше будет разрабатываться на S 1.4.
                0
                Мы для себя решили так: большие и сложные новые проекты делаем на sf2. Просто потому, что там будет мало использоваться наш проверенный и хорошо изученный стек плагинов. А мелочь и старые проекты ведем дальше на форкнутом на всякий случай 1.4.
            +1
            Лично скажу по себе, то стоит задуматься а стоит ли? Symfony1 и Symfony2 не более чем один и тот же бренд и те же разработчики.
            Но идеология всего фреймворка Symfony2 совсем иная. Это уже скорее Spring.
            Стоит ли менять идеологию веб-разработки — решать вам. Но к симфони1 намного ближе тот же Laravel (основан кстати на симфони компонентах), ну и тем более ближе Rails. Всё конечно зависит от целей и задач, но не делайте из изучения нового языка огромную преграду. Используйте то что удобно и эффективно, а не то что популярно.
              0
              Вопрос скорее в преграде при НЕ изучении новых возможностей языка/фреймворка.
                0
                В существующем проекте действительно не стоило бы переходить на Symfony2. Если, конечно, бюджет проекта не резиновый или другая какая причина. Просто переход на Symfony2 будет означать, что придется переписать проект с нуля.

                Новый проект начинать на Symfony 1.4 не советую.
                  0
                  Почему не советуете? Только ли потому что 1.4 не поддерживается?
                    +1
                    Нет, не только. В целом, я работал с Symfony 1.4 столько же, сколько работаю с 2. И, скажу, что на Symfony2 можно делать более качественные решения, более быстрые и более легкие в поддержке. И тратить при этом только же вермени, сколько и на symfony 1.4.

                    Но все же поддержка играет ключевую роль в OSS. OSS это труд многих и многих людей. И представьте, что Все эти люди сейчас не работают над тем, чтобы сделать именно ту технологию, которую вы используете лучше, быстрее, надежнее.
                +1
                С документации конечно. Есть 2 базовых статьи — теоретическая: чем sf2 отличается от sf1 ( symfony.com/doc/current/cookbook/symfony1.html ) и практическая: как создать страницу на sf2 (Creating Pages in Symfony2 symfony.com/doc/current/book/page_creation.html ).

                После неплохо было бы проштудировать book и хотя бы ознакомиться с содержанием cookbook. Однако на это рассчитывать не приходится )
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Спасибо, поправлю.

                  Да, конечно, я имел ввиду критичные исключения. Те, которые могут быть исправлены сразу же, должны быть исправлены сразу же в вызывающем коде. Но в любом случае, не хорошо ловить исключения в контроллере. Критичные исключения будут обработаны на уровень выше, а некритичные не должны дойти до контроллера.
                    0
                    А так плохо?

                    Контроллер:

                    try {
                        $model->save($user);
                        echo 'ok. user saved';
                    } catch (DuplicateEntryException $e) {
                        echo 'error. user already exists';
                    }
                    


                    DuplicateEntryException бросает обертка над PDO (при нарушении unique constraint):

                    class DB {
                        //constructor, etc
                        public function query($query) {
                            try {
                                $this->pdo->query($query);
                            } catch (PDOException $e) {
                                switch ($e->errorInfo[1]) {
                                    case 1062:
                                        throw new DuplicateEntryException($e->getMessage());
                                   //other codes
                                    default:
                                        throw $e;
                                }
                            }
                        }
                    }
                    
                      0
                      Да, так плохо :)
                        0
                        Что не так? Как бы сделали/делаете Вы?
                          +1
                          Ну все зависит от того, что именно Вы хотите сделать. По двум кусочкам кода это не очевидно. Но уж точно, что за сохранение сущности контроллер не должен отвечать.

                          Собственно, и логику обработки исключения стоит пренести туда, где вы будете сохранять эту сущность. Или же, если выхотите сделать это поведение общим, что более логично, т.к. DuplicateEntryException может быть выброшено и при попытке сохранить другую сущность в БД, Вам было бы лучше перевыбросить исключение другого типа, добавив к нему сообщение, которое вы будете показывать пользователю. Неплохо было бы добавить интерфейс, по-которому вы будете в дальнейшем определять, что нужно вывести в браузер сообщение для пользователя. И это, другое исключение централизованно ловить уже в EventListener symfony.com/doc/2.1/cookbook/service_container/event_listener.html.

                          Я бы сделал так.
                            +1
                            Но уж точно, что за сохранение сущности контроллер не должен отвечать.

                            В последнее время прихожу к тому, что сохраняться как раз все по максимуму должно в контроллерах, а вся остальная логика не должна работать с БД, максимум persist. Т.к. все эти хаотичные flush в сервисах начинают сильно портить жизнь. А написать метод контекста, для выделение абстракции лишь для сохранения сущностей, по мне так слишком большой overhead.

                            p.s.
                            Выполнять все в транзакции, для того что бы контролировать стихийные flush — это безусловный костыль, который лишь позволяет разработчику ещё более сильно запутать код.
                              0
                              Вы flush делаете в контроллере. Это другое.
                                –1
                                Извините, получается я не правильно понял, что такое «сохранение» в вашем контексте.
                  +7
                  Совет номер ноль: использовать Symfony только в тех проектах, что вписываются в Symfony'вский «стандарт» по функционалу.

                  К сожалению, Symfony слишком сложен. Монструозная конфигурация. Монструозное кол-во абстракций (одни только формы чего стоят). Как следствие — крайне трудная отладка, а также обучение новых сотрудников. Написание своих сервисов — тот еще танец с бубном, т.к. документация тут уже слабая.

                  В одном нашем проекте была чуть более «нестандартная» система авторизации, чем предполагает Symfony Security. После пары дней research'а от Security осталось очень мало, а остальной огромный кусок кода заменился одним, нами написанным, лаконичным сервисом.

                  В нынешнем проекте система безопасности еще более хитрая и в стандартную Symfony'вскую вообще не вписывается. Ну или вписывается кране слабо. В итоге вся Symfony Security была отключена вообще под ноль. Но проблем доставила другая часть фреймворка — формы.

                  Резюмируя, напишу так. Если вы понимаете как работает Symfony, как работают его части и почему там именно так все написано, а также плюсы и минусы этих решений, то, если у вас проекты не шаблонные, Symfony можно выкинуть. Причем во многих случаях даже нужно выкинуть. Ибо проще поддерживать, условно, 50 классов + ORM, чем воевать с огромным фреймворком.
                    –1
                    Это первоапрельская шутка же, да?)
                      +3
                      Нет.
                      Тут я более чем согласен с автором комментария. Если вам нужен не сложный проект, то более чем стоит его создавать на Yiiframework.
                      Если же хотите писать большой проект на длительный срок поддержки, то выбора у вас нет, нужно смотреть на Symfony 2, даже только лишь потому, что Yii 1 версии уже скоро не будет поддерживаться и развиваться, а остальные framework'ки не выдерживают никакой критики.

                      p.s.
                      В нашем проекте мы так же выбросили и формы и авторизацию из Symfony
                        0
                        Вопрос выбора платформы — сугубо лчиное. Выбор есть всегда и если Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Yii ;)
                          +1
                          Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Yii ;)

                          Что за глупости?
                            0
                            Нет, почему же глупости.

                            Вам что-то не понравилось в формах, и в секьюрити, Вы взяли этот компонент и выбросили, благо в Symfony это легко сделать.

                            Я правда считаю, что в таком случае лучше юзать другой фреймворк, Yii я привел только потому что вы о нем говорили.

                            Вопрос еще на что Вы это заменили. Если на другую более или менее популярную библиотеку, то еще ок. Если же вы свой велосипед сделали, то не ок.
                              0
                              Вам что-то не понравилось в формах

                              Очень тяжело расширяемый, не предоставляющый необходимых возможностей компонент.
                              К тому же, почему вы рассматриваете Symfony как обертку над формами?

                              Я вообще не понимаю ваше отношение к Yii.
                              В этом framework'е свои компоненты. Можно с равной степенью заявить, как и вы:
                              и Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Symfony
                                0
                                Что то мы в Оффтоп ушли, ну да бог с ним :)

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


                                Насчет расширяемости не согласен. Но, некоторые вещи мне, конечно и самому не нравятся. Например, то что я должен в форм тайпе решить, как я хочу отрендерить поле.

                                А насчет возможностей? Просто ради интереса, чего Вам не хватает?

                                > К тому же, почему вы рассматриваете Symfony как обертку над формами?

                                Не рассмтариваю, где вы это усмотрели :) Просто концепция форм вписывается в общую концепцию фреймворка. И мне действительно удобно работать с формами в симфони в 95% случаев.
                                  0
                                  А насчет возможностей? Просто ради интереса, чего Вам не хватает?

                                  Например поля нет в Entity. Обращение к полямпроисходит через некий Manager сущности.

                                  Ну и ещё 1 usecase:
                                  Внешний вид формы может быть чуть ли не произвольным и задаваться пользователем.
                                    0
                                    > Например поля нет в Entity. Обращение к полямпроисходит через некий Manager сущности.

                                    Ну такова уж особенность форм, точнее паттерна DataMapper. Вам нужен объект или массив, чтобы забиндить его в форму. И так же вы из формы получаете объект или массив. Потом делайте с ним что хотите. Если у Вас как-то по-другому это работает, nо можно копнуть глубже и посмотреть как компонент устроен внутри. Скорее всего вы решите задачу используя события. Возможно Вы сможете решить задачу используя symfony.com/doc/current/reference/forms/types/form.html#property-path

                                    > Внешний вид формы может быть чуть ли не произвольным и задаваться пользователем.

                                    Вот тут вообще проблемы не вижу :) Вплоть до того, что пользователи сами будут шаблоны для форм и полей делать.
                                      +1
                                      можно копнуть глубже и посмотреть как компонент устроен внутри

                                      слишком сложно, гораздо проще делать так:
                                      example.html.twig: {{ widget($field) }}
                                      И людей проще этому обучить(на два порядка), и отлаживать на много удобнее.

                                      Вот тут вообще проблемы не вижу :) Вплоть до того, что пользователи сами будут шаблоны для форм и полей делать.

                                      Наверное я не правильно объяснил. Суть в том, что бы пользователь работал с WYSIWYG, со вставкой служебных конструкций для определения полей.
                                        0
                                        слишком сложно, гораздо проще делать так:


                                        ну а {{ form_widget(form) }} Вам чем не так? Вообще мы говорили о маппинге данных в поля формы или как?

                                        Суть в том, что бы пользователь работал с WYSIWYG, со вставкой служебных конструкций для определения полей.


                                        Ну а я о чем, берете сырые данные из WYSIWYG сохраняете, чтобы их отредактировать позже можно было. Обрабатываете служебные конструкции, чтобы получить параметры (переменные, которые потом используете), делаете себе Twig шаблон. Переменные сетите во вью формы. Или вы не то же самое делаете? Возможно, у Вас есть прослойка, которая служебную информацию сразу в html рендерит. Ну так разницы никакой, кто за рендеринг отвечает.
                                          0
                                          ну а {{ form_widget(form) }} Вам чем не так? Вообще мы говорили о маппинге данных в поля формы или как?

                                          То что внутрь передается некий form, который нужно описывать до потери сознания, а внутри я ещё и ограничен чем только можно.

                                          Ну а я о чем, берете сырые данные из WYSIWYG сохраняете, чтобы их отредактировать позже можно было. Обрабатываете служебные конструкции, чтобы получить параметры

                                          Что-то я почти ничего не понял, что вы предлагаете. Можно больше деталей?
                                          Как подсунуть нужны шаблон для Symfony Forms?
                                          Как маппить конкретное поле в конкретный form_widget?
                                          Как в сложные виджеты передать список возможных значений для конкретного поля?

                                          Я всё это вообще не представляю в данной концепции.
                                            0
                                            Я всех Ваших требований не знаю, но на вопросы Ваши отвечу.

                                            Как подсунуть нужны шаблон для Symfony Forms?

                                            Механизм шаблонов очень простой он использует имя формы для определения шаблона. Также Вы можете использовать темы. Т.к. для форм используется паттерн Composite, вы можете иметь сколько угодно тем как для конкретного поля, так и для форм в общем.

                                            Как маппить конкретное поле в конкретный form_widget?

                                            Можно определять форм тайпы, можно билдить формы динамически, как Вам больше нравится.

                                            Как в сложные виджеты передать список возможных значений для конкретного поля?

                                            Если речь идет о селектах, то через опции. Так же можно сетить переменные во view непосредственно.
                                          0
                                          А разве нельзя переопределить шаблоны форм/функцию для вызова форм?
                                  +3
                                  Отлично, что делать когда вам никто не дает денег на парк серверов, а нагрузки предвидятся нехилые такие? Можете сами замерить сколько Symfony жрет памяти на один запрос. И сколько минимум времени надо на выполнения кода простенького контроллера без запросов в базу.

                                  Вот не получается у меня что-то с формами. Я лезу в доку, проверяю, что все норм, а все равно не работает. Лезу в гугл, экспериментирую с кодом, но все равно не работает. Открываю дебагер, а там просто нереальное кол-во абстракций.

                                  У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?

                                  По поводу «легко что-то отключить». Попробуйте отключить security, а потом создать свой SecurityBundle. Вас ждет неприятный сюрприз, т.к. Symfony будет думать что в системе есть *стандартный* extension «security». Ок, лезем в наш класс SecurityBundle\DependencyInjection\SecurityExtension, переопределяем метод getAlias(). Теперь начинает падать класс SecurityBundle\SecurityBundle, т.к. там идет проверка alias'а (нафига???).

                                  Зачем-то поля формы можно задавать классом. Ок, а почему через аннотации можно указывать параметры валидации, а вот какие именно виджеты для каждого поля выводить — нет? Есть 3rd-party bundle, видел, да. Только вот меня он не устроил.

                                  Почему html5 validation, в частности атрибут pattern не подставляется автоматом, когда указываешь в списке валидаторов Regex? Да, код в Symfony для этого есть, только вот не работает.

                                  Почему когда я делаю бандл с namespace'ом аля Organisation\Department\SomeBundle, то resource locator'ы перестают искать шаблоны по строке что-то типа «SomeBundle:controller:view», когда делаешь все в точности по официальной доке? Привет часик с дебагером.

                                  Как уже мною упоминалось выше, программирование валидации настроек бандлов — это вообще треш.

                                  И таких мелких и не очень минусов там огромное кол-во. Проблема в том, что мы не штампуем по 5 сайтов за месяц. У нас проекты меньше полугода не длятся. И несмотря на то, что штат сотрудников огромный, PHPшников мало (я и сам одновременно на java пишу). А знакомых с Symfony вообще почти нет. И что делать, когда на проект с Symfony приходит менее компетентный коллега, который далеко не факт, что сможет продраться с дебагером под мышкой через эту кучу кода? Что, он меня дергать будет non-stop?

                                  Что вам такого дает Symfony на крупных проектах, чтобы его так защищать? Модульность? Простоту тестирования? Так ничто не мешает написать слабосвязанный код и без Symfony. ServiceConainer'ер хочется? Так не вопрос, за адекватное время спокойно пишется свой, пусть и куда менее функциональный, но так этого и не надо. Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request. И читабельность кода не пострадает. И т.д. «Идеальная архитектура», «100% покрытие тестами», «быстрое и легкое внесение изменений» — это лишь мифы. Да, к этим целям надо стремиться, но никогда не стоит забывать что серебряной пули не существует и всегда лучше сдать проект в срок, чем пытаться сделать супер-пупер код.

                                  Стоит добавить, что подобные рассуждения применимы не везде и не всегда. У вас относительно краткосрочные или шаблонные проекты? Куча PHPшников в фирме, которые *уже* Symfony знают? Не хватает квалификации чтобы без фреймворка написать слабосвязанный код? Тогда, да, юзаем Symfony и не паримся.

                                  Так что, если резюмировать, то отказываться от Symfony так сразу я не предлагаю. Но и думать, что данный фреймворк — серебряная пуля тоже не надо. При выборе технологии всегда голову включать надо.

                                  Возможно, в будущем мнение изменится на противоположное. А, может, ситуация, например, на рынке труда изменится. Но на данном этапе моей карьеры мне видится ситуация вот так.

                                  ЗЫ: Да, я знаю о синдроме «not invented here». Не во всех случаях, к сожалению, его упоминание будет к месту.
                                    –2
                                    Отлично, что делать когда вам никто не дает денег на парк серверов, а нагрузки предвидятся нехилые такие?
                                    Писать на Erlang. Разве кто-то утверждает, что sf2 создан для хайлоада?

                                    Проблема в том, что мы не штампуем по 5 сайтов за месяц.
                                    Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?

                                    У вас относительно краткосрочные или шаблонные проекты?
                                    Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.

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

                                    Так что, если резюмировать, то отказываться от Symfony так сразу я не предлагаю. Но и думать, что данный фреймворк — серебряная пуля тоже не надо. При выборе технологии всегда голову включать надо.
                                    Точно. Только я так и не понял, откуда следует, что отказываться от sf2 вообще надо.

                                    Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
                                      +1
                                      > Писать на Erlang. Разве кто-то утверждает, что sf2 создан для хайлоада?
                                      Отлично, а Erlang так много народу знает? Или заказчик возьмет и радостно оплатит обучение команды, по вашему? Я-то только за, только вот одного моего желания мало. Бывают чисто объективные причины в виде бюджета и сроков или недостатка сотрудников, а бывают и политические.

                                      Я как-то привык сначала код писать, а потом только с профайлером его оптимизировать. Конечно, выбор адекватных алгоритмов еще на этапе написания никто не отменял. Так вот в случае с Symfony очень тяжело понять что с ним можно сделать в плане оптимизации, несмотря на то, что там куча всего в PHP код кешируется и bytecode кешер включен.

                                      > Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?
                                      Инструмент на *этот* проект, согласен, выбрали неверно. Это моя ошибка. Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен. Вопрос в том, обосновано ли он такой сложный. Имхо, нет.

                                      > Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.
                                      А что делать с проектами, для которых CMS не подходит, а фреймворк хочется, чтобы самим кучу кода не писать? 90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?

                                      > Не хватает. Не каждый коллектив разработчиков являет собой лигу выдающихся джентльменов.
                                      Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.

                                      > Да и новых сотрудников искать проще, указывая в требованиях к кандидату опыт работы с конкретным фреймворком.
                                      Новых сотрудников искать проще? Да еще и конкретный фреймворк указывая? Да ладно? Вы в курсе о ситуации на рынке труда сейчас? Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!

                                      На всякий случай, о конторе. Когда я год назад менял работу, то предложений было очень много и я имел возможность сам выбирать работодателя. Так так контора у нас вполне нормальная. Былая адекватная зарплата, которая всегда выплачивается срок, разные плюшки типа ДМС. Возможность самим выбирать технологии на проект и даже менять язык разработки. Сказать что контора слабая и не способна привлечь хотя бы средних спецов явно нельзя. А вот, тем не менее, два месяца поисков.

                                      Впрочем, похожая ситуация сейчас и в других фирмах — интересовался.

                                      > Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
                                      Вы можете воспринимать мой комментарий как угодно. Я просто описал мой опыт и взгляд на текущую ситуацию с Symfony.

                                       

                                      Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.
                                        0
                                        Отлично, а Erlang так много народу знает?
                                        Я утрировал, говоря об Erlang. Почему бы не разрабатывать на Java?

                                        Или заказчик возьмет и радостно оплатит обучение команды, по вашему?
                                        Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.

                                        Я как-то привык сначала код писать, а потом только с профайлером его оптимизировать. Конечно, выбор адекватных алгоритмов еще на этапе написания никто не отменял.
                                        Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу. И при этом не говорю, что php плохой язык.

                                        Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен.
                                        Я и не говорил, что проблема в количестве сотрудников, я сказал, что вы выбрали не тот фреймворк, а возможно, и язык. В мире php не так часто встречаются паттерны сложнее синглтона, а sf2, как вы справедливо заметили, состоит из одних абстракций — но ведь это всё ради удобства разработки. Программистам, впервые видящим все эти фабрики и контейнеры, остаётся только впасть в академический транс — думаю, в этом виноват не только фреймворк.

                                        90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?
                                        Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?

                                        Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.
                                        Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?

                                        Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!
                                        Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.

                                        Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.
                                        Возможно, вы правы, но я честно стараюсь быть объективным.
                                          0
                                          > Я утрировал, говоря об Erlang. Почему бы не разрабатывать на Java?
                                          К сожалению, жависты крайне плохо дружат с вебом, а, особенно, с клиентской стороной. Был как раз выбор между Java и PHP. По разным причинам выбрали PHP, хотя, возможно, мы и пожалеем об этом выборе.

                                          > Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.
                                          Тем не менее, чтобы писать что-то, не уходящее особо за рамки tutorial'ала, много времени на обучение на надо. Когда полезли глубже, стало понятно что попали.

                                          > Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу.
                                          Под фразой «выбор адекватных алгоритмов еще на этапе написания» понимались только совсем очевидные случаи, типа индексы в базе расставить. Это если утрированно. В целом же, придерживаюсь такого же подхода.

                                          > И при этом не говорю, что php плохой язык.
                                          У меня о PHP по сравнению с той же Java резко негативное мнение, но чтобы не разводить срач, ограничусь просто этой фразой.

                                          > Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?
                                          Исходя из документации и статей типа этой, когда все преподносится таким простым. Кроме того, был некий опыт уже с Symfony и относительно удачный. Но, да, это решение было ошибочным.

                                          > Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?
                                          Я предлагаю прежде всего думать головой. И банально не надеется что Symfony или иной другой фреймворк решит все проблемы. Если очень упростить, то предлагаю 10 раз подумать о выборе конкретного фреймворка, если разрабатываемый функционал выходит за рамки его tutorial'а.

                                          > Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.
                                          Тут, возможно, вы правы.
                                      +1
                                      Не лень же Вам было коммент писать :) Вы поймите меня правильно, я вовсе не идеализирую фреймворк. И вовсе не делаю по пять проектов в месяц. И цель моя не холивары холиварить, а помочь людям, тем кто хочет на этом фреймворке делать приложения :)

                                      У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?

                                      Юзер берется из токена в секьюрити контексте. Попадает он туда в процесса аутентификации. Изменить можно создав свой провайдер аутентификации.

                                      Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request.


                                      Простите, у меня всего один вопрос к Вам. Понимаете ли вы почему глобальные переменные, это зло? :)
                          +3
                          В большинстве случаев создание web-приложений подразумевает «стандартный» функционал.

                          Symfony не сложен, но, да согласен, у него высокий порог вхождения. И да, секьюрити и формы самые сложные компоненты.

                          Да, много абстракицй. Но много из них являются фундаментальными и они хороши.

                          Резюмируя, скажу. Если вы любите минимализм, то не юзайте ORM. Это не тру. Как и не тру «изобретать велосипеды», это не Symfony way :)
                            +1
                            Symfony не сложен, но, да согласен, у него высокий порог вхождения.

                            Вы уж определитесь.
                              0
                              Под высоким порогом вхождения я понимаю уровень знаний разработчика в общем, необходимый для начала работы. Под сложностью, время которое нужно потратить разработчику на изучение фреймворка, если он этими знаниями обладает.
                                +1
                                Для меня, высокий порог вхождения в framework и есть его сложность. Я никак не могу представить что «уровень знаний разработчика» есть «порог вхождения». Даже Русский язык против составления такого предложения.

                                p.s.
                                На мой взгляд, Symfony действительно сложен. По сравнению с ним, для меня, Yii изучается чуть ли не более чем целиком за 2 дня.
                                  0
                                  «Порог» и «уровень» синонимы. В отличи от «сложность» и «порог», которые не имеют ничего общего.
                                    0
                                    «Порог вхождения» нельзя разделять. Это устоявшееся выражение.
                                      +1
                                      Я объяснил свою точку зрения. Видимо, Вы думаете иначе. Это Ваше право.
                                    0
                                    Все паттерны и методы решения определенных задач, применяемые в Symfony2, существовали задолго до его появления.

                                    Если специалист с ними раньше работал, то освоить фреймворк не должно составить труда.
                                      0
                                      Спасибо, Inori :) Именно это и имел ввиду.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Ох, как я Вас понимаю! Так было сложно без админ генератора первый месяц и казалось, что к Twig'у никогда не привыкну.
                                  0
                                  — Меня зовут Андрей и я 4 месяца разрабатываю на Symfony2. До этого все пилил свой CMS.
                                  Я вот быстро привык к twig'у. Когда первый раз увидел его в документации symfony2, то сразу понял, что хочу шаблоны делать именно на нем. Да еще и с PHPStorm — идеально… Разобрался с DI, MVC использовал и в своем CMS, проблемы с переполнением памяти при работе с dotrine исправил, меняя свой код, а вот с формами проблема. Вот сейчас не могу понять, как правильно сделать форму, количество полей в которой может меняться на стороне клиента…
                                    +1
                                    Меня зовут Андрей и я 4 месяца разрабатываю на Symfony2


                                    Прям клуб анонимных Симфонистов какой-то :)

                                    Вот сейчас не могу понять, как правильно сделать форму, количество полей в которой может меняться на стороне клиента.


                                    Если Вы имеете ввиду коллекции, symfony.com/doc/master/reference/forms/types/collection.html то вся магия вот в этом классе github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php.

                                    Если есть какие-то конкретные вопросы. Спрашивайте, я помогу.
                                      0
                                      Если есть какие-то конкретные вопросы. Спрашивайте, я помогу.

                                      Сделать бы нормальный форум анонимных симфонистов, а то все что я видел(рускоязычные) заброшены, или там два-три человека
                              0
                              Артем, отличная статья! :) Еще я кажется знаю, с какого проекта приполз абзац об интерфейсах ;)
                                0
                                Саш, спасибо! Насчет интерфейсов, ты прав :)
                                0
                                Спасибо за статью! Я только начал изучать этот фреймворк и у меня есть один насущный вопрос. Как сделать расширяемую форму? То есть у формы есть какая-то статическая часть + динамическая, например название компании, адрес и описание — статическая, сотрудники — динамическая. На клиенте JSом добавляются поля, но как-то обработать без костылей стандартными средствами фреймворка можно?
                                  0
                                  Судя по всему Вам нужно использовать FormType Collection symfony.com/doc/current/reference/forms/types/collection.html. У него есть специальный элемент, prottotype. Вы можете рендерить prototype где-нибудь на странице, а потом вставлять этот prototype через JS в форму сделав замену $$name$$ на уникальное значение.

                                  Более частный случай, если у Вас есть полиморфная сущность. Например у Вас несколько типов сотрудников с разными полями и Вы хотите иместь возможность выбрать какую форму Вам нужно вставить на страницу (например, выбирая нужный элемент из бутсраповского dropdown-button). Тогда Вам не подойдет стандартный Collection и нужно будет сделать свой FormType и добавить к нему небольшой Listener.
                                  +2
                                  Используй стабильные версии бандлов, если есть такая возможность. А если нет, то обновляй зависимости как можно чаще. Ошибки лучше всего исправлять по мере их появления. Когда ты насобираешь много обновлений, то и устранить все проблемы несовместимости, будет намного сложнее.

                                  Недавно пытался собрать Symfony из стабильных пакетов.
                                  — Невозможно

                                  Сколько уже проекту лет, а все равно используешь dev пакеты — позор.
                                    0
                                    Так версии бандла определяется разработчиком бандла. Сам фреймворк выпускает стабильные версии.
                                      0
                                      Хм, а так не? github.com/symfony/symfony-standard/blob/master/composer.json

                                      Я имелл ввиду, что есть 3-d party bundles. Для которых нет еще стабильных версий. Их то и нужно обновлять почаще.
                                        0
                                        { ...
                                            "minimum-stability": "stable",
                                        }
                                        

                                        и не соберется, скорее всего :)

                                        Я имелл ввиду, что есть 3-d party bundles. Для которых нет еще стабильных версий. Их то и нужно обновлять почаще.

                                        Да мы как бы даже не собераемся 3d party bundles использовать, лишь все от SensioLabs. Но собрать stable до сих пор нет возможности. Вот этим я сильно раздосадован. Что за prodaction на dev решениях?
                                          0
                                          Да, как бы соберется :) Вы бы проверяли информацию, перед тем, как высказываться :)
                                            0
                                            Проверил, не собралось.

                                            Problem 3
                                            — symfony/assetic-bundle v2.1.2 requires kriswallsmith/assetic 1.1.* -> no matching package found.
                                            — symfony/assetic-bundle v2.1.1 requires kriswallsmith/assetic 1.1.* -> no matching package found.
                                            — symfony/assetic-bundle v2.1.0 requires kriswallsmith/assetic 1.1.* -> no matching package found.
                                            — Installation request for symfony/assetic-bundle 2.1.* -> satisfiable by symfony/assetic-bundle v2.1.0, symfony/assetic-bundle v2.1.1, symfony/assetic-bundle v2.1.2.
                                              0
                                              Да, вы правы. AsseticBundle использует нестабильную версию assetic. Сработает install с стабильностью dev, потом меняем стабильность на stable и делаем update. Собственно, как я и проверил в первый раз.

                                              Впрочем, если для Вас важно, чтобы у Вас в конфиге было stable. То юзайте 2.1:

                                              2.1 соберется
                                              {
                                                  "name": "symfony/framework-standard-edition",
                                                  "description": "The \"Symfony Standard Edition\" distribution",
                                                  "autoload": {
                                                      "psr-0": { "": "src/" }
                                                  },
                                                  "require": {
                                                      "php": ">=5.3.3",
                                                      "symfony/symfony": "2.1.*",
                                                      "doctrine/orm": ">=2.2.3,<2.5-dev",
                                                      "doctrine/doctrine-bundle": "1.1.*",
                                                      "twig/extensions": "1.0.*@dev",
                                                      "symfony/assetic-bundle": "2.1.*",
                                                      "symfony/swiftmailer-bundle": "2.1.*",
                                                      "symfony/monolog-bundle": "2.1.*",
                                                      "sensio/distribution-bundle": "2.1.*",
                                                      "sensio/framework-extra-bundle": "2.1.*",
                                                      "sensio/generator-bundle": "2.1.*",
                                                      "jms/security-extra-bundle": "1.2.*",
                                                      "jms/di-extra-bundle": "1.1.*",
                                                      "kriswallsmith/assetic": "1.1.*@dev"
                                                  },
                                                  "scripts": {
                                                      "post-install-cmd": [
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
                                                      ],
                                                      "post-update-cmd": [
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
                                                          "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
                                                      ]
                                                  },
                                                  "extra": {
                                                      "symfony-app-dir": "app",
                                                      "symfony-web-dir": "web",
                                                      "branch-alias": {
                                                          "dev-master": "2.1-dev"
                                                      }
                                                  }
                                              }
                                              

                                                0
                                                {
                                                 "kriswallsmith/assetic": "1.1.*@dev"
                                                }
                                                

                                                Не смущает, ну ладно…
                                                Только не надо утверждать что это @stable. Там явно тянется последний commit master branch.

                                                И это ладно мы рассматриваем bundle в стандартной поставке. А если взять хотя бы doctrine/doctrine-migrations-bundle то вообще пиши пропало. \dev на \dev и \dev погоняет
                                                  0
                                                  Ну вообще, в стандартной поставке идет и composer.lock файл. Который гарантирует, что выполучите не последнюю версию из мастера, а ту с которой симфони гарантированно работает. Но, если же Вам непременно нужно определнный стабильный тэг, Вы можете сделать так.
                                                  {
                                                   "kriswallsmith/assetic": "1.1.0-alpha4"
                                                  }
                                                  

                                                  В данном случае composer update не приведет к обновлению версии assetic. Тоже самое касается и миграций и всех остальных бандлов. Эта хорошая практика, когда вы в репозитории храните composer.lock. Впрочем и сам composer тоже в альфе до сих пор. Но как-то, привыкли уже с этим жить :) На продакшене устанавливаете через composer install. Если хотите обновиться делаете локально composer update. Прогоняете тесты, все ок – комититесь, не ок – исправляете несовместимости и комититесь. Все просто :)
                                                    0
                                                    Но как-то, привыкли уже с этим жить

                                                    Да это всё понятно :)
                                                    Но я и негодую по этому поводу — не порядок.

                                                    К тому же, если взять какой либо дополнительный Bundle, то просто нет возможности не уйти в полный dev.
                                                    И это — ужасно.
                                      0
                                      Еще вопрос по консоли. Очень удобная штука, возможно такое восхищение от того что это первый фреймворк.
                                      Подскажите есть ли обертки вокруг консоли, позволяющие постоянно в ней работать, кроме SensioLabs Desktop?
                                      У меня есть свой велосипед, но он не очень прост и много чего не умеет делать, на пример запоминать историю и выводить по нажатию кнопки вверх.
                                      Сам велосипед
                                      #include <iostream>
                                      #include <string>
                                      
                                      using namespace std;
                                      
                                      int main()
                                      {
                                          string path, command, full;
                                          cout<<"Console path: ";
                                          cin>>path;
                                          path = "php " + path + " ";
                                          while(true){
                                              cout<<"Command: ";
                                              cin>>command;
                                              full = path + command;
                                              system(full.c_str());
                                          }
                                      }
                                      

                                        0
                                        Попробуйте php app/console --shell
                                          0
                                          Странно, на чистом проекте любая команда выскакивает с исключением [RuntimeException] Too many arguments.
                                        +1
                                        С тех пор, как я влюбился в Assetic и консоль, даже небольшие проекты делаю на Symfony2.
                                          0
                                          после 3 месяцев проб тоже все понравилось, правда пока медленно все это
                                          +1
                                          После начала работы с symfony2 подготовил парочку скриптов на питоне. Один делает мне новый проект с готовой стандартной структурой, другой обновляет выбранный проект в продакшен на сервере (с очисткой кеша и т.п.).

                                          В целом все нравится. Единственное, что смущает, это скорость разработки. С одной стороны много всего готового, а с другой в своем, скажем так, «устаревшем фрэймворке» мне приходилось писать гораздо меньше, чтобы сделать какую-нибудь новую логику с таблицами, сущностями и т.п. И пока что в голове еще не сложилось, как достичь той же скорости.

                                          Есть вопрос.
                                          Не делай сервисы зависимые от контейнера

                                          Я делаю в сервисах бизнес-логику, которая работает с сущностями. Получаю я EntityManager через контейнер. Раз это плохой стиль, то какое решение? Хотя бы если doctrine передавать в конструктор — это нормальный стиль? Или как лучше в сервисе работать с сущностями тогда?
                                            +1
                                            Да, Doctrine уже лучше. Еще лучше, если только EntityManager (doctrine.orm.default_entity_manager). Т.е. только то, что Вам реально необходимо.

                                            Просто если у Вас будет контейнер в Сревисе, вы не будете правильно определять зависимости класса, а будете дергать все из контейнера. Это потом протестировать, продебажить, отрефакторить очень тяжело.

                                            Позвольте также дать пару советов по сервисам:

                                            1. Используйте yaml для конфигурации, он гораздо легче читается.
                                            2. Не нужно делать праметров для класса сервиса, как в документации. Эти параметры нужны, чтобы можно было подменить класс в 3dparty бандле, если нужно его заоверрайдить. В своем проекте вы всегда можете это сделать ручками, но читабельность конфига повысится.
                                            3. Используйте команду php app/console container:debug (можно сокращать до cont:de) + grep, чтобы найти нужный сервис.
                                            4. Делайте класс, пишите не него тесты. И только потом, конфигурируйте его как сервис в контейнере.
                                            5. Делайте приватными те сервисы, которые нужны только как засисмости для других сервисов. Т.е. если вы не дергаете нигде сервис из контроллера, но используете только как засимость для другого сервиса.
                                            0
                                            Вот все великолепно в статье… Ох с примерами бы еще по каждому из пунктов, цены бы не было. Можно было смело распечатывать и с собой носить. Тем не менее огромное спасибо за статью.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое