Andrey Kulikovsky

1. Мэтт Зандстра "PHP: объекты, шаблоны и методики программирования" - Врубиться в ООП
   
2. Эрик Фримэн и ко "Паттерны проектирования" (Head First) - Влюбиться в ООП
   
3. Эрик Эванс "Предметно-ориентированное проектирование" - научиться проектировать сложные системы
   
4. Крэг Ларман "Применение UML 2.0 и шаблонов проектирования" - про проектирование, глубокое понимание ООП
   

Мы делаем всегда поддомен, если нельзя сделать адаптиву, вида m.domain.com.
Сеошники думаю подскажут лучше. Но у нас только на одном клиентском проекте моб. версия закрыта для поисковиков, остальные же не парятся по этому поводу.

Мы используем JWT для авторизации.
Годный бандл - https://github.com/lexik/LexikJWTAuthenticationBundle + в доке указаны сторонние (для cors и т.д.)
Для ангуляра - есть много решений или свой провайдер очень легко реализовать.

Описание jwt - jwt.io + на хабре было несколько статей.

Continuous Integration (https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D...

1. В symfony-standart app.php - это prod-окружение, для дева - app_dev.php или смотрим строчку в app.php:
$kernel = new AppKernel('prod', false);
2. Ssh нужен, любой нормальный хостер предоставляет ssh.

А вообще, думаю, начать стоит с документации по фреймворку - symfony.com/doc/current/index.html

Лучше создаввать конкретный экземпляр класса, вида RedisCacheProvider реализующий общий интерфейс, наприер CacheProviderInterface.
Подсмотреть можно здесь: https://github.com/doctrine/cache

Также, создание объектов я бы вынес в DI-контейнер. И почитайте про инверсию зависимостей (если нужно).

Как вариант можно поискать на github сайты самих фреймворков или опен-сорс решений.
Например: https://github.com/laravel/laravel.com

Если выгружать сущности полностью:

$query= $this->
            ->createQueryBuilder()
            ->select('b, users')
            ->from(B::class, 'b')
            ->join('b.users', 'users')
            ->where('b.id = :id')
            ->setParameter('id', $id)
            ->getQuery();

Обращаем внимание на строчку select('b, users')

PS. И Doctrine довольно сложный инструмент, как выше советуют - читайте документацию.

1. Мэтт Зандстра "PHP: объекты, шаблоны и методики программирования" - Врубиться в ООП
   
2. Эрик Фримэн и ко "Паттерны проектирования" (Head First) - Влюбиться в ООП
   
3. Эрик Эванс "Предметно-ориентированное проектирование" - научиться проектировать сложные системы
   
4. Крэг Ларман "Применение UML 2.0 и шаблонов проектирования" - про проектирование, глубокое понимание ООП
   

Ваш класс очень похож на объект бизнес-логики (domain entity).
Предпочтительно использовать при создании объекта и установки значений конструктор (entity всегда должна быть валидной) и постараться избавиться от внедрения зависимости через конструктор, например так:

public function updatePassword($plainPassword, PasswordEncoderInterface $encoder) {
    $this->password = $this->encoder->encode($plainPassword);
}

Если у нас множество вариантов создания объекта, удобно использовать именованные конструкторы, такого вида:

public static function create($userName, $email) {
    $user = new self();
    $user->username = $username;
    // ...
    return $user;
}

public static function createFromMyVariant($uid) {
    $user = new self();
    // ...
    return $user;
}

Купить второй впс (много места, остальное по минимуму) и лить туда всю статику любым удобным способом (ftp, ssh и т.д.).

ActiveRecord имеет смысл использовать, если ваша модель хорошо ложаться на реляционную структуру данных. Т.е. свойства классов соответствуют полям таблицы.

Для сложной бизнес логики - лучше доктрина, она маппит данные из таблиц на наши доменные объекты и структура таблиц субд может сильно отличаться от структуры нашей модели. Также доктрина включает много замечательных штук таких как UnitOfWork, EntityManager и кучу других удобных вещей.

Для большинства сайтов и несложных проектов active record - хороший вариант. Для сложных проектов - Doctrine.

Про использование orm vs pdo выше ответил OnYourLips

1. Никаких сеттеров. Entity всегда дожна быть валидной (установка значений через конструкторы, именованные контсрукторы). Если нужно менять состояние - делаем осмысленные методы, типа:
   

   public function updatePassword($plainPassword, EncoderInterface $encoder) {
       //...
   }
   public function updateProfile(UserProfile $profile) {
       //...
   }

   
   
2. Вадидация должна происходить в приложении на более высоких слоях. (Валидируем request, command и прочее).
   
3. Очень удобно использовать Embedded-object (doctrine-orm.readthedocs.io/projects/doctrine-orm/... в качестве Value-objects.
   
4. flush() всегда делаем в контроллере (в верхнем слое приложения) и забываем про такую конструкцию $em->flush($myEntity); Суть такая: наше приложение работает с бизнес-объектами (domain-objects), меняет их состояние, однако про сохранение (коммит изменений) слой модели не должен знать, это не его задача. Все изменения фиксируются в конце запроса.
   
5. Используйте Domain-events - очень удобная штука.
   
6. Иногда очень полезно отказаться от автогенерации доктриной id, можно использовать uuid.
   

И дострина многим не нужна, часто достаточно active-records.
Doctrine даёт большой профит только если доменна логика сложная, ну все это хорошо ложится на проектирование по модели (DDD).

Если PHP. то Symfony3 - отлично ложиться на средние и большие проекты + LTS релизы.

Как вариант эти фрагменты нарезать на минишаблоны и после их инклудить:

{# fields/_ first_field.html.twig #}

<div class="place-for-first-field">
    <div class="list of classes for first field">		
        {{ content.getField('first_field')  . . .  }}
    </div>
</div>

И инслудим в шаблон:

{{ include('fields/_ first_field.html.twig', {'content': myContent}) }}

Если возвращаемые значения объекты и имеют фиксированное поведение (и отображение) и постояно реюзается в различных проектов можно создать TwigExtension, но это трудозатратнее.