voronkovich

Помимо уже указанного выше, почитайте про 12-факторные приложения, там ключи и пароли рекомендуется конфигурировать через переменные окружения. 12factor.net/config
Соответственно, сами конфигурации, можно хранить в системе контроля версий.

Есть хорошая книга выдающегося польского математика Вацлава Серпинского 250 задач по элементарной теории чисел. Она замечательна тем, что в ней даны задачи, решение которых не предполагает знаний высшей математики. При этом сами задачи достаточно трудны и имеют очень короткие формулировки и решения.

Вторая книга, которую я бы порекомендовал - книга советского математика Хинчина: 3 жемчужины теории чисел. В данной книге описаны решения 3-х трудных задач для которых были найдены решения с применением элементарной математики (без всяких диффуров и гомотопий!). Решением одной из описанных задач, в свое время занимался сам Гильберт.

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

Один из разработчиков доктрины советует следовать принципу:

Модель всегда должна находиться в валидном состоянии.

Соответственно, передавать обязательные поля в конструктор - хорошая практика.
См. слайды с описанием лучших практик для доктрины: Doctrine best practices.
Сама доктрина, для установки данных использует механизм рефлексии.

Если crud'ов много я использую SyliusResourceBundle. Для всего остального - отдельные контроллеры.
Есть подход: один контроллер - один класс. С autowiring это может быть реализовано очень легко.

Возможно, вам может помочь form-handler-bundle

Для примера можете посмотреть Symfony. Там для взаимодействия между "триадами" используются объекты Request и Response.
HttpKernelInterface

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

Просуммирую сказанное в комментариях:

Плюсы аннотаций:

• можно быстро писать код, прототипировать (особенно если используете сниппеты), т.к. и описание маршрута и код находятся в одном месте.
  

Минусы аннотаций:

• Невозможно "окинуть взгядом" (в YAML это проще);
  
• Иногда (очень редко) из-за них нужно менять порядок следования action-методов в контроллере т.к. нужно чтобы какой-то маршрут "срабатывал раньше".
  

Стоит отметить, что по возможностям и аннотации и yaml -одинаковы.

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

Sylius

Для создания API есть Lionframe.

В Symfony-контейнере случай описанный для Laravel работать не будет.
Сделайте без autowiring. Или добавьте для зависимостей сеттеры, тогда контейнер внедрит их автоматически:

<?php
class Some
{
    public function setDependencyA(DependencyA $a)
    {
        $this->dependencyA = $a;
    }

    public function any()
    {
         $this->dependencyA->someMethod();
          // do something 
    }
}

В ваше коде есть несколько проблем. Возможно, если вы устраните их, то все заработает.

1. У вас нет обработки загрузки файла. Его нужно сохранять вручную.
Пример: https://github.com/symfony/symfony-demo/pull/286/files

В контроллере нужно обработать все загруженные файлы следующим образом:

foreach ($product->getImages() as $image) {
    $uploadedFile = $image->getFile();
    $uploadedFile->move('uploads/', $uploadedFile->getClientOriginalName());
    $image->setPath('uploads/' . $uploadedFile->getClientOriginalName());
}

И почитайте внимательно symfony.com/doc/current/cookbook/doctrine/file_upl...
Также посмотрите api.symfony.com/3.0/Symfony/Component/HttpFoundati...

2. Во всех формах укажите data_class, и тогда не нужно будет создавать экземпляр Image вручную.
См. symfony.com/doc/current/reference/forms/types/form...

3. Вам не следует делать вызов метода getForm() внутри buildForm

4. Начиная с симфони 2.8 объявление метода getName не нужно. Теперь формы идентифицируются по полному имени класса.

Аннотированный исходный код есть у Backbone и Underscore.

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

Например, я недавно искал хороший компонент для маршрутизации для Python 3, в духе Symfony, но не нашел.
Может сделаете? :)

Также могу порекоммендовать книгу Н. Вирта "Создание компиляторов". В ней описывается как создать простой компилятор языка Оберон. Реализуйте его на питоне.

Успехов!