Сергей Протько

Стоит ли все function собирать в одном файле?

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

И стоит ли плодить около 5-10 функций для разборчивости кода?

Стоит. Это называется декомпозицией. Когда вы одну большую задачу (отобразить страницу) дробите на маленькие подзадачи. Велик шанс что на других страницах что-то из этого пригодится. Да и просто так удобнее. Маленькое проще править чем большое.

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

погуглил за вас.

unix.stackexchange.com/questions/136548/force-comm...

функции Login, SetCredentials и т.д. являются методами сервиса AuthenticationService.

Фабрика - это способ задания сервиса. Разница между .service и .factory лишь в том, что в первом случае вы засовываете конструктор объекта, а во втором - функцию фабрику которая сама разберется как объект создавать.

// вот сервис
function MyService (dep1, dep2) {
    this.dep1 = dep1;
    this.dep2 = dep2;
}

// А вот фабрика этого сервиса
function myServiceFactory(dep1, dep2) {

    return new MyService(dep1, dep2);
}

// в результате в контейнере зависимостей будет крутиться
// 2 инстанса одного и того же сервиса. То есть одинаковый результат
// при двух подходах.
module.service('foo', MyService)
module.factory('bar', myServiceFactory);

В вашем примере фабрика используется баналь потому что надо где-то сделать объект и для этого используется "модуль". Ну мол для инкапсуляции и т.д. Что бы не экспоузить зависимости вашего объекта никому. Ну а Object.create просто для слабых духом.

1. шаблонизатор - это просто компонент. Они ничего не знает о MVC и прочем булшите
2. шаблонизатор нужен там, где формируется view. Вы можете крутиться как хотите, но view на бэкэнде пассивно (это http ответ) в подавляющем большинстве реализаций (даже в ADR от которого нынче писают кипятком), а это значит что формироваться view будет в контроллере. Отсюда делаем вывод что шаблонизатор должен дергаться в контроллере а такого компонента как view у нас просто нет. Возможны хэлперы которые помогают формировать этот самый view но не более.
3. управление зависимостями не входит в зону ответственности MVC. Оно обычно где-то сверху, тут можно заюзать Dependency Injection (только готовый контейнер если, свой не пишите).
4. трейты в контроллерах нормальная тема просто потому что на код контроллеров нам должно быть плевать с высокой колокольни. Если вам не плевать на код контроллеров - возможно вы там делаете что-то чего контроллеры делать не должны. Ну и опять же это будет трейт который будет делегировать задачу шаблонизатору а не реализовывать его.
5. что-то мне подсказывает что "модель" в вашей системе координат это какой-нибудь класс для работы с базой данных. Если так - вы не поняли зачем вообще вводится это разделение.

передавайте данные явно через биндинги.

Есть ли порог когда использование ОРМ становится неоправданым/оправданым? Где он?

ORM-ки нужня для одного конкретного типа систем - OLTP (On-line Transaction Processing)

У меня в приложении есть модуль который работает с бд Solr

У вас есть документы, в документно ориентированных базах данных нет связей. Потому вам нужен Object Document Manager а не Object Relational Mapper.

Каждый документ может имеет поле parent в котором сохранен ид-родителя, дальше ид-прародителя, дальше прапрародителя итд.

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

бд в режиме read-only

Тогда точно не нужна ORM/ODM.

Итд. Иногда какая-то дополнительная трансформация.

Но это же трансформация на уровне формирования результата выборки, так? Если так - то это опять же не та проблема.

Нужен спец по ООП и UML, который работал в своё время с MVC!

Наблюдаю тут несостыковку. Обычно когда говорят о UML - вот все эти вещи вроде контроллеров и т.д. расписываются на уровне компонентов. В UML обычно описывают только доменную логику, то есть то что важно.

В любом случае в Yii такие подходы работают очень плохо. Там вы не ООП делаете а базу данных проектируете (это чуть разные вещи), и все остальное уже от этого отталкивается.

Если вы хотите по UML фигачить (не понятно зачем правда, но это уже ваше дело), то имеет смысл брать какую ORM заточенную под ОО-first (по сути Doctrine2 из ныне существующих) и там уже развлекаться. Там профит будет.

p.s. забудьте об этой бесполезной для бэкэнда аббревиатуре MVC. Пока вы "проектируете контроллеры" - толку от него нет (ну то есть пока у вас логика работы с данными в контроллере).

Читаю GOF, Зандстру и т.п.

Почитайте Applying UML and Patterns - Craig Larman - замечательная книга. Еще дядю боба можете почитать (про SOLID). Если вас интересуют темы проектирования то это будет полезно. Еще раз уж заговорили о проектировании логики предметной области - Эрик Эванса - Предметно ориентированное проектирование.

Задача 1

1) композиция всегда лучше наследования
2) наследование нужно для того что бы организовать подтипы. Если у вас есть сущности которые по своей природе требуют наследование - то можно. А так - лучше его избегать. ООП как бы не про наследование вообще.
3) интерфейсы нужны для того что бы организовать инверсию зависимости и/или полиморфизм подтипов. У Лармана можете почитать про protected variations для того что бы понять зачем их юзать.

Задача 2

В UML отношения между типами очень легко и просто отображаются:

- Base[classname] - wrappers для обеспечения ровного обновления самого Yii в дальнейшем, не обращайте внимания.

Как это не обращать внимания если вы делаете UML ради UML? Пока я не увидел ничего от ООП на вашей диаграмке. Есть структуры данных с публичными пропертями, есть... контроллеры (внезапно) которые мутируют состояние этих структур.... Это не ООП - это процедурное программирование с классами.

для такой простой задачи я пилю UML исключительно в целях тренинга

Пока это выглядит как впустую потраченное время, поскольку вы выбрали не лучший инструмент (yii) что бы тренироваться проектировать ОО решения.

Я рекомендовал бы вам:

- Разобраться что такое ООП на самом деле (это не про инкапсуляцию. полиморфизм и уже тем более не про наследование ибо все это было еще до ООП и все это кроме наследования является важными принципами структурного программирования). Это про сокрытие состояния и управление зависимостями (связанность, coupling & coheasion у Лармана)
- Взять более подходящие для проектирования ОО решений инструменты (какой-нибудь модный нынче Laravel + Doctrine2)
- если хотите продолжать баловатся с Yii сделайте так, что бы логика предметной области ничегошеньки не знала о Yii, тогда вообще не нужно будет заниматься этими Base* классами. Почитайте про Row Data Gateway (это по сути предшевственник ActiveRecord) а именно как оно использовалось в контексте модели предметной области.

Есть ли под это паттерн?

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

Оригинальная книга по GoF в этом плане так себе, сейчас лучше смотреть в сторону Head First Design Patterns Ну и помимо паттернов нужно разобраться с общими принципами такими как закон деметры, SOLID, GRASP и т.д. Тогда понимание всего будет более системным.