Алексей Солодкий: так а что вас смущает? Фабрика как минимум должна знать кого она должна создавать. Все остальные зависимости ей передают (часть в конструктор и часть в параметрах). Все хорошо.
desuvin: я просто инлайню сгенеренные css правила в страницу и не парюсь особо. Загрузка нужных изображений начинается сразу, надежно и даже не нарушает никаких там правил БЭМ-а и прочее.
Алексей Солодкий: и да, для меня сервис, это обычный класс который не влазит в слой предметной области. Все те классы которые указывают доменным моделям направления действий и занимаются такой грязной работой как сохранение в базу, кеширование и т.д.
1) вместо EntityManager можно инджектить напрямую репозиторий. И убрать flush из сервиса и перенести его куда-нибудь на уровень выше. Я к примеру делаю flush перед отдачей респонса в большинстве случаев (на уровне ивентов http kernel). Иначе пользы от Unit of work предоставляемого вам доктриной не особо много.
2) merge можно вынести в TransactionsCollection так как ему там самое место. Затем можно заперсистить всю коллекцию одиним махом.
3) Не уверен, но мне кажется что setSource надо делать в loadTransactions и передавать туда accountSource вместо sourceParams. Но это я не трогал ибо не знаю бизнес логики.
4) Не понятно почему у вас accountContextFactory умеет сохранять контексты... тогда это не фэктори а репозиторий.
5) С перечисленными изменениями в том виде в котором вы скинули можно заDRYить обработку транзакций и объеденить все в insertTransactions.
Думаю можно еще код почистить и поразносить. Скажем loadTransactions вообще вынести в репозиторий.
Knokout позволяет сделать только привязку данных (организовать viewmodel) а angular много чего еще. Соответственно выбирать надо исходя из того что нужно сделать.
Artur Aralin: он примитивный и покрывает только самые базовые нужды. rest-angular уже пожирнее в плане возможностей, но лично мне не нравится оный. Но пока альтернатив более достойных я не встречал.
Сам же я использую свои обертки над $http (для изоляции интерсепторов при работе с несколькими API ну и другие плюшки для работы с моделями и т.д.).
Nc_Soft: да, и все это выполняется исключительно во вью, не затрагивая контроллер никоим образом. Контроллер должен только сказать "отдай ему в респонсе отрендренную вьюшку" и экспоузит для нее данные. А уже внутри View происходит вся эта канитель с установкой заголовков, закардкожены они или же из базы берутся - дело третье.
Mikhail Osher: https://github.com/johnpapa/angularjs-styleguide - в принципе большинство из этих правил стоит соблюдать, часть (особенно по структуре директорий, ограничение мол один компонент на файл и т.д. на личный вкус, но общая идея должна быть понятна.
Виктор Выскребенцев: ну.... не знаю.... тут главное понять основной смысл, DRY и упрощение процесса внесения изменений в систему. А там дальше идет понимание принципов ООП, GRASP-вские принципы и только потом стоит браться за GoF.
Stopy: какой именно? MVC? Ну наверное... то что методология хорошая и позволяет развязать систему (бизнес логику и логику представления введя дополнительный компонент - контроллер - который руководит парадом).
