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

примеры из повседневной речи:
<..> и генератор будет йилдить до тех пор пока <..>
<...> каждый раз йилдит новый джоб <...>
для разговорной речи этого более чем достаточно.

более литературно и по русски:
<...> он будет отдавать значения с шагом в 10 единиц <..>
<..> должен выдавать срез заданного размера <...>

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

Многое несомненно зависит от того как позиционируется PHP бэкенд в составе проекта,
однако в целом если говорить про разработку приложений на PHP как такового (без зоопарка вокруг)
список инструментов примерно следующий (представлены самые популярные)

Стандарты - по хорошему надо прочитать и понять всё что издает php-fig в сфере юзерленд кода,
самые важные - PSR 0-4

Вспомогательные (обязательные) технологии - YAML, XML, CSV, JSON;
Библиотеки "все-в-одном" - на бэкенде не водятся (да здравствует linux-way);
Фремворки общего назначения, скелеты приложений - Yii (1,2), Symphony2, ZendFramework2;
CMS-фреймфорки - Drupal, ... Wordpress? ищите под задачу;
Модульность, Зависимости - Composer и все что с ним связано, PEAR/PECL (потихоньку отмирает);
Сборка - Phing (хотя я собираю php-проект gulp'ом - у него API приятнее);
Тестирование - PHPUnit, Behat, CodeCeption;
Деплой(Развертывание релизов) - Mage (aka Magallanes), Deployer
Помощники - Vargant, Docker (тестирование и разработка в готовых окружениях)

Здесь я не упоминал того что нужно знать о самом языке и его компонентах.

теперь поговорим о зоопарке..

технологии и зоопарк специфичный только для PHP:

Сервера приложений - php-fpm, apache-mod-php;
Кэш и быстродействие - APC (APCu для PHP >= 5.5)
дебаг - ZendDebug, XDebug, XHProf

Далее то что не отличается от одного серверного языка к другому.
это часть ответа безгранично велика на самом деле =)

Сервера и прокси - Nginx, Apache, Varnish, etc.
Кэши и NoSQL - Memcached, Redis, Mongo, etc.
СУБД - MySQL, PostreSQL, etc..
Поисковые индексы - ElasticSearch, Sphinx
Очереди и межпроцессовое взаимодействие - RabbitMQ, ZeroMQ, linux-sockets, posix-treads
Протоколы взаимодействия (4 уровень OSI) - HTTP(во всех его подробностях! просто MUST HAVE), POP, SMTP, IMAP, REPL.
Траспортные Протоколы (3 уровнь OSI) - TCP, UDP
Библиотеки уровня системы - cURL (абсолютный MUST HAVE - большинство взаимодействия поверх HTTP строится на этой библиотеке в абсолютном большинстве серверных скриптовых языков)

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

Как говорят другие ответчики - D3lphi и Александр Шаповал , контроллер должен содержать минимум логики, и нет "единого правильного способа" его реализовать.

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

Контроллер, каким бы он не был и как бы не организовывался - содержит только обработку входных данных (валидация и преобразование) и преобразование выходных данных в нужный формат

Логика и оркестрация которая в 80% случаев и является предметом спора о том как стоить контроллер (речь всех этих вызовах сервисов, управления потоками данных между ними, последовательности действий и пр), находятся в отдельном классе согласно паттерну Unit of Work - что позволяет легко покрыть все что связано с логикой вменяемыми юниттестами без танцев с бубном.

Т.е. структура в итоге такая:

{view} <--> {controller} <---> {unit_of_work} -->>> {{{..lots of services...}}}

по сути класс семейства UnitOfWork - это полный сценарий обработки входных и выходных данных , с оркестрацией потоков данных и порядком действий, возможно какой то мелкой вспомогательной логикой, эдакий фронтенд над сервисами, заточенный под каждое конкретное действие извне (сам паттерн предполагает что класс создается на каждый отдельных случай и почти один в один описывает UseCase логику как она пришла от бизнеса (заказчика/аналитиков/моей головы/etc).

Сами классы семейства UnitOfWork (имеется ввиду в одном приложении) могут иметь собственные иерархии наследования и композии - в угоду бизнес логики и дабы не дублировать код - главный критерий - это полная независимость бизнес и сервис слоев от контроллера. - что и является на мой взгляд "каноничным" вариантом реализации композии M и C в MVC.

У меня, как у человека который не пишет фронты в принципе (имею ввиду сам UX/UI), но постоянно занимается сервисами, рестом, библиотеками - этот подход выработался по одной просто причине:
взаимодействие с командой, я предоставляю "библиотеку"(не в классическом понятии этого слова) полностью абстрагированную от любых фронтов, оттестированную, полностью функциональную - а люди пишут к ней шаблонные обвязки где только валидация данных и рендер нужного формата под HTTP/Sockets/AMQP/etc типа всяких там CRUD/REST или RPC