пример дико упрощен, и не забываем что в моем случае мне не надо писать миграции или делать схему базы руками. Я просто запущу doctrine:migration:diff и doctrinte:migration:migrate.
OnYourLips: хз, доктрина использует plain old php objects что лично в моем случае серьезно так поднимает скорость разработки. А с 2.5 версии можно value objects хранить спокойно, что позволяет наконец уйти от анемичной модели и радоваться жизни, загоняться по DDD и не жерствовать читабельностью кода в угоду скорости разработки.
Александр N++: в Yii2 запилили identity map-ы? Я с 2012-ого просто не слежу за событиями.
Например
$user = new User('Sergey');
$foo->user = $user;
$bar->user = $user;
// где-то сильно позже
$foo = Foo::find(1); // я не помню точно API yii2
$bar = Foo::find(2); // так что извините если что
assert($foo->user === $bar->user);
А вы пробовали симфони? Или точнее пробовали ли вы доктрину? (воспринимайте как соц опрос, думаю статейку написать и интересует мнение тех кому она не нравится). Вообще не представляю как писать поддерживаемый код с active record.
Знаете, если смотреть на ugoria.js то там и без тестирования проблем хватает. Контроллер директивы не должен работать с DOM, вся работа с DOM должна быть вынесена в link. Но это мелочь. Так же не понятно зачем там $compile, насколько я виду это все можно сделать просто указав templateUrl.
Собственно вот эту директиву полюбому надо покрывать тестами, ибо ее надо будет рефакторить в первую очередь.
Сервис keys.js вы тестами особо и не покроете, так как там идет взаимодействие с глобальными элементами какими-то, какой-то jquery... вообще мега стремная штука. Вот эта штука должна быть директивой. Вообще вы не должны использовать выборки по селекторам в angular (только в ооочень редких случаях).
faragly: прочитать можно в документации. Юнит тестами скажем стоит покрывать только фильтры, сервисы, директивы. В идеале у вас не должно быть контроллера конкретного состояния и т.д. но если оно и есть - это покрывается только e2e тестами. Взаимодействие с API обычно выносится так же в отдельные сервисы, которые покрываются только e2e тестами, а везде просто мокаются. Писать на все тесты или нет - решать вам. Покрывать тестами все подряд тоже не гуд, ибо если опыта в этом мало есть риск написать кучу тестов которые тестируют сами себя.
Написание тестов всегда дает одно - возможность производить рефакторинг чаще за счет минимизации рисков регрессий. А частый рефакторинг залог чистой архитектуры и уменьшения технического долга.
faragly: Лично я для юнит тестов выбрал jasmine потому что все остальное то же самое и профита я не увидел в других вариантах. Больше веселья с e2e тестами, тут хоть варианты есть. Опять же у меня бэкэнд покрыт behat-ом (аналог cucumber) так что писать e2e на cucumber.js казалось логичным (с четом того что часть тасков для установки прекондишена просто отправлялась на сервак, чем уменьшалось дублирование кода).
Petr_Anisimov: сам по себе flex-shrink не расчитывается, он указывается и по умолчанию равен единице. А уже shrink factor расчитывается на его основе, и там это описано.
xfg: оукей, а куда девается вью? Как в эту модель вписываются запросы/ответы? Кто отдает ответ?
Есть классическая слоеная архитектура
1) приходит запрос на слой интерфейса, он передается в контроллер, который является эдаким медиатором между слоями
2) контроллер забирает данные запроса и дергает сервис (Application layer) какой-нибудь который занимается оркестрацией действий, описывает флоу конкретной фичи (по сервису на фичу). То есть там могут быть как конкретно бизнес правила, так и просто обращения к другим сервисам (domain layer) которые знают маленькие кусочки работы ну и т.д.
3) после того как наш сервис уровня приложения отработал, он выплевывает объект наружу, который содержит все необходимые данные для формирования из него представление. Контроллер уже определяет (по заголовкам запроса или еще как) какое представление мы хотим получить и генерит ответ и возвращает его обратно в слой интерфейса.
Все остальное, фреймворк, active record, компоненты и т.д. - слой инфраструктуры. Сама же бизнес логика ничего о вашем фреймворке особо знать не должна.
Правда если всему этому следовать выходит что active record бесполезен и надо юзать Doctrine, так как альтернативы пока нет(
vasIvas: angular (особенно вторая его версия) и есть компонентный фреймворк, и это круто. Это то что мне в нем нравится.
Что до чувака который пишет логику в модели - если при этом сохраняются принципы единой ответственности, если все согласно шаблону "информационный эксперт" и все такое то не вижу в этом ничего плохого. Вы зациклились на MVC, просто забейте. Жить станет намного проще. Есть куда более важные вещи о которых надо париться.
vasIvas: на счет вэба не согласен, html это чисто шаблоны, view layer это не только html + css.
хз, можно сколько угодно разглагольствовать по плюсах минусах и прочим, а можно просто писать код. Я пожалуй займусь вторым. Буду продолжать искать баланс в толстоте контроллеров.
vasIvas: мне на самом деле очень будет любопытно почитать. Пока же я не понимаю одного - вы говорите что взаимодействие через контроллеры это тип не ок и что должны быть медиаторы, хотя контроллер это как раз таки медиатор между view и model.
https://gist.github.com/fesor/db2dd19e71a40ed2297b
пример дико упрощен, и не забываем что в моем случае мне не надо писать миграции или делать схему базы руками. Я просто запущу doctrine:migration:diff и doctrinte:migration:migrate.