Владимир Чернышев

В репозитории. Модель простой POPO, о БД вообще ничего не знает, её единственная область ответственности — моделировать предметную область. Ответственность репозитория — хранить сущности модели, где и как только он знает. Как вариант, да, прокси, реализующий тот же интерфейс, что и «чистый» репозиторий. Другой вариант — кэшировать результаты запросов ещё ниже, где-то на уровне DBAL/DAL. Но на практике только прямо в репозитории реализовывал, что-то вроде

class UserRepository {
  public function getById($id) {
    if ($this->cache->hasKey('user' . $id)) {
      $user = $this->cache->getByKey('user' . $id);
    } else {
      $user = $this->db->getUserById($id);
      $this->cache->set('user' . $id, $user);
    }
}

В symfony вроде как контроллер вовсе не обязан быть классом. Вернее классом он не может быть в принципе. Может быть методом класса, может быть функций, в общем любым callable.

Если же вообще имеется в виду код глобального неймспейса без какой-либо обёртки (практически «спагетти»-код, только с разделением M и V), то категорически против — сильно затрудняет какое-либо совместное использование, потому что переменные любого контроллера становятся переменными глобального неймспейса.

Большей частью (модульные) фреймворки и пишутся для реализации функций контроллеров, связи вида и модели. Слово «библиотека» тут не совсем уместно. Библиотеку вызывают из своего кода, а контроллер и есть свой код прежде всего. Вы можете в каком-нибудь users.php написать код получения списка юзеров из Doctrine и его рендеринг в Twig и это будет типичный контроллер, но когда придёте к концепции фронт-контроллера и роутинга, чтобы соблюдать DRY хотя бы, то получите типичный велосипедный фреймворк.