Простите, а как связан принцип инверсии зависимостей и юнит тесты? Имхо, грамотную архитектуру нужно строить опираясь на SOLID, а не на возможные тесты.
Спасибо за развернутый ответ. Вопрос в догонку: почему бы не решать вопрос структуры базы ее отсутствием, а именно не использовать доментоориентированные базы?
Это не бред. Просто такой стиль построения API не всегда подходит, что еще раз показывает что серебряной пули не бывает. Замечательная статья по теме есть у Steve Klabnik.
А не могли бы вы поподробней рассказать почему на проектах выбрали именно EAV модель данных? Несколько раз приходилось сталкиваться с подобным, но осознать плюсов подхода так и не смог.
Достаточно интересно с первого взгляда.
Наличие генератора для C#, возможно, позволило бы использовать некую общую базу (бизнес-логику) для разработки нативных приложений для всех мобильных платформ.
Тут у меня скорее вопрос: в чем преимущество behavior?
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.
Простите, это как? Конструктор в PHP (как и почти во всех ОО языках) не обладает блоком возврата.
Наличие генератора для C#, возможно, позволило бы использовать некую общую базу (бизнес-логику) для разработки нативных приложений для всех мобильных платформ.
Имхо, такого рода задачи это бесценная практика.
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.
Прекрасная фраза, надо обязательно взять на вооружение.