Керим Бердимырадов: нет, не будет. Я имел в виду сервисный слой. В рамках сервисного слоя $em вы должны использовать только в репозиториях (это не конкретно доктриновские репозитории а любой сервис который отвечает за доставку данных. У меня например есть парочка репозиториев которые напрямую мэпят данные не на сущности а на DTO при чтении).
Керим Бердимырадов: ну в идеале это все должно быть спрятано где-нибудь на уровне ивентов кернела, тогда доктрина вообще спрятана с глаз, но по опыту могу сказать что с таким подходом возникают проблемы.
Наиболее удобным вариантом пока является flush в контроллере. Если говорить в терминах гексагональных/слоеных архитектур, то контроллер это такая же часть инфраструктуры как и база данных. потому использование там entityManager-а более чем допустимо.
По сути не столь важно где вы это будете делать, важно что flush должен происходить один раз на запрос (мы предполагаем что у нас одна транзакция на запрос, могут быть ситуации когда мы в рамках одного http запроса делаем несколько транзакций, но это разруливается опять же в контроллере путем нескольких вызовов сервисов, например для пакетной обработки данных).
Alexander: это комбинаторика, раздел высшей математики, тоесть той математики о которой вы узнаете в ВУЗе если пойдете в него.
В целом же тут я виу только факториалы чисел, не помню в каком классе в школьной математике проходят факториалы (если еще проходят, в физ-мате проходили на 10-м 11-м классах).
Ну и опять же - это формулировка в математическом виде, считать ничего не надо, надо читать. Видите ли, "искусство программирования" это не книжка для школьников, там рассказываются основы, но в академических терминах, для будущих инженеров. То есть ее обычно дают на первых курсах ВУЗов и расчитана она на людей с определенным уровнем знаний.
Вячеслав Лебедев: стили - нет предпочтений. Нравится postcss то активно не использую (только автопрефиксер)
по core-js - это коллекция полифилов. Ну то есть это дополнительно к babel который только транспайлит. Недостающих функций и т.д. оно не добавит. А грузить весь набор полифилов при том что используется процентов 10 как-то не круто.
Wolfak: имейте в виду что при таком подходе у вас файл сначала в память загрузится и потом только на диск. Ну то есть для больших чанков файлов это не годится.
Stalker_RED привел пример потокового чтения и записи, который записывает все по 255 байт (можно увеличть и грузить по нескольку килобайт за раз). Буферизованные пайпы еще можно делать и все такое.
Вячеслав Лебедев: модули ангуляра не нужны когда есть ES6 модули. Это рудимент. Благо сегодня вышел angular2 лишенный этого "недостатка". Но в былые времена да, это было удобно.
Вячеслав Лебедев: решает конечно, у меня все проекты на ES6 за последние пол года (чуть меньше пожалуй).
По "куче проблем" - у меня ангуляр приложение по структуре чуть отличается от той, которую можно увидеть в "полуофициальном" yoman генераторе. И под "чуть" я подразумеваю "сильно". Компонентный подход, модульность и т.д. То есть без грамотной системы модулей уже тяжко.
Пока спасало только то что в ангуляре есть свои модули, но иногда всеравно случаются косяки связанные с ресовом зависимостей и т.д.
Так же щаблоны. С gulp я собирал шаблоны в templateCache и не парился, с webpack я тупо импортирую их внутрь компонентов (шаблоны только для них) и далее с ними орудую. А так как я еще и jade использую то это все просто дико удобно.
Стили - делать стили модульными можно и так, но очень легко поддаться соблазну и сделать какую-нибудь зависимость. Да и со штуками типа css modules удобно использовать, правда я пока только пробовал и боюсь переходить на них.
webpack выдерет из core-js только те полифилы которые реально мне нужны (так как я явно прописал зависимость от оных). Это как бы и с другими бандлерами работает, тут просто преимущество бандлеров над тупой конкатенацией. С gulp (имею в виду без бандлинга) же мне пришлось бы подключать весь core-js или лепить кастыли.
D' Normalization: ну я о том же говорю, инструмент надо выбирать под задачу. У меня например приложеньки на ангуляре, много разных, минимум сотенка JS файлов, надо как-то зависимости между ними ресолвить и т.д. И с gulp-ом было норм но как-то сложно поддерживать. Вводим нормальные модули - уже лучше. Вводим бандлеры - замечательно.
А для простого сайтика я бы webpack не брал конечно. Хотя сайтики разные бывают.
Антон Натаров: это норм, но только не в сервисах это делать. Вообще вся проблема с этими "менеджерами" решилась бы введением интерфейса единого, тогда можно было бы дублирование вынести в декоратор, и скейлилось бы это лучше. Но мое мнение - логику такую лучше спрятать в сущность или вообще избавиться от нее. Запоминать только что кому и сколько + коммисию. Ничего не считая, просто запомнить действие. А посчитать по этим действиям сколько у нас сейчас денег мы всегда сможем.
D' Normalization: я тоже был примерно такого же мнения, webpack смотрится слегка противоестественно. Но по итогу я решил попробовать и пока доволен, так как он решил целую гору моих проблем со сборкой проектов.
Если у вас SPA, то полюбому нужны модули. А если есть модули - то лучше воспользоваться бандлерами. От gulp-а я к слову не отказался.
