s5656: не знаю о чем вы, почти всё из симфони мне удаётся использовать без самой симфони. доктрина, разве что, голову морочит. а про зенд - согласен, я скорее говорил о всяких поделках вроде уии или ларавела, которые сами по себе один большой антипаттерн
Я правильно понимаю, что если принять условия задачи "один сервис - один канал", то вот таких Definition-ов мне потребуется ровно столько, сколько у меня сервисов и инжектить вот такие custom logger-ы придется в каждый мой сервис? Или же я могу пометить тэгом _свой_сервис_ и в него будет инжектирован логгер, настроенный на определенный канал?
а на мой взгляд плохой фреймворк с протекающими абстракциями будет только мешать делать нормально. по этому параметру симфони точно будет лучшим выбором - он меньше всего навязывает архитектурных решений пользователю
Лично мне кажется минималистичный интерфейс php-шного клона https://www.npmjs.com/package/pimple куда интуитивнее и привычнее.
Публичное апи в виде get/set/factory/protect вполне логично и достаточно.
Имхо, клиент контейнера не должен знать фабрично ли бы создан инстанс сервиса или это переиспользуемый объект. Чем меньше вызывающая сторона знает о реализации сервиса - тем лучше. Навскидку примеров когда они и тот же сервис нужно инстанциировать и фабрично и единоразово я не смог придумать.
Архитектура у Pimple довольно минималистична, но при этой ей сильно не хватает разве что явной заморозки контейнера, остальные все моменты проработы нормально
Мне кажется, в вашем лучше всё-таки сначала собрать самую-самую базу пакета, сделав ее понятной и простой, добившись четкости и прозрачности апи, а а потом уже сверху ее обвешивать autowiring-ом, аннотациями и прочим жирком. Сейчас за этим кодом очень сложно даже понять, что это, оказвается, DiC.
bears: так, а как мне из вложенного group убрать всё, кроме его id? то есть меня в целом устраивает Item вида
{
"name": "bar",
"group": {
"id": "8215471f-834b-49fa-8a32-ff4a2f849bdf"
}
}
Но я не хочу иметь вложенную Group со всеми ее полями. Я могу сделать ненужным полям Exclude в самой Group, но тогда в GET /groups я их тоже не увижу, а там они нужны. Как быть?
Я добавил аннотацию Inline - всё, связанное с group вообще исчезло при get. Вообще бог с ним, с JMS, мне показалось, что у его автора в целом не очень качественные библиотеки.
Но неужели в 2015 году на таком замечательном фреймворке как sf2, нельзя просто организовать шаблонное RESTful API?
Современный nginx умеет проксировать TCP и умеет LUA. Быть может, попробовать выразить логику этой балансировки на LUA, вместо поисков готовых решений? Впрочем, в haproxy тоже есть LUA, но я не знаю что можно с его помощью там сделать.
Андрей: в таком случае, у пользователя появляется дубликат. Если он это заметит (нет покупок, например), то можно ему предложить объединить оба аккаунта (назовем их аккаунт A - старый - и аккаунт B - новый). Технически, это будет выглядеть примерно как update social_account set user_id = ACCOUNT_A.id where user_id = ACCOUNT_B.id и delete from app_user where id = ACCOUNT_B.id.
Таким образом удалится и дубликат и у "старого" юзера появится привязка новой соцсети
Андрей: да Иван: это просто принципиальная схема, без лишних усложнений. Мы пока полагаемся, что если пользователь сумел подтвердить мыло в соцсети, то мы автоматом считаем его доверенным. Но если приложение критично к пользовательским данным - то да, лучше спросить владельца явно.