ну вот я подумал про джаву тоже

питонисты борятся с GIL

а пыхеры даже не знаю с чем)

php-ники борятся со здравым смыслом

php-ники просто радуются жизни)

php-ники просто радуются жизни)

http://www.nytimes.com/images/blogs/freakonomics/posts/happic.jpg

Народ подскажите как правильно реализовать такое с точки зрения архитектуры. Дано приходит по soap объект из внешней системы, в объекте могут отличаться поля например может быть юр лицо а может физ соответственно набор полей тоже будет отличаться. и надо засунуть все это добро в другую систему, типа CRM.

Написать процедуру маппер?

адаптер

Народ подскажите как правильно реализовать такое с точки зрения архитектуры. Дано приходит по soap объект из внешней системы, в объекте могут отличаться поля например может быть юр лицо а может физ соответственно набор полей тоже будет отличаться. и надо засунуть все это добро в другую систему, типа CRM.

ETL паттерны

https://sourcemaking.com/

У этих сайтов один и тот же автор)

У этих сайтов один и тот же автор)

Странно тогда...типо у него был сайт на английском а он решил сделать урезанный рерайт + перевести на русский и украинский?

про требования не согласен, наооборот живем в золотой век где на работу всех подряд берут

ответственно заявляю, как человек сидевший без работы год, что это не так Хуёвая статистика, но чёт больно долгий срок

значит мы с разных планет =( Можно мне плс билет до вашей планеты? Спс!

Ребят, по поводу паттерна "Repository" Вот смотрю на эту статью ( https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/ ) и вижу что в интерфейсе описано много методов которые могут формировать различную логику, допустим поиск побольшому количеству входных параметров. Но составление запросов в зависимости от условий, что если пользователь установил такой флаг в GUI то и запрос должен формироваться соответственно другой и в репозитарий уже должны передаваться данные чистые, а логика соответственно должна быть в том же "сервисном слое" Правильно я понимаю. Да и это не php головного мозга ;)

Ребят, по поводу паттерна "Repository" Вот смотрю на эту статью ( https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/ ) и вижу что в интерфейсе описано много методов которые могут формировать различную логику, допустим поиск побольшому количеству входных параметров. Но составление запросов в зависимости от условий, что если пользователь установил такой флаг в GUI то и запрос должен формироваться соответственно другой и в репозитарий уже должны передаваться данные чистые, а логика соответственно должна быть в том же "сервисном слое" Правильно я понимаю. Да и это не php головного мозга ;)

все эти репозитории, особенно для элоквента - это оверинжинииринг. и народ который юзает... обычно юзает их не оттого что реальная необходимость возникла, а потому что... "вот неплохо бы заюзать чтото модное... хорошо звучащее, паттерн!!!"

Всем привет. Как лучше называть сервисы? Допустим сервис занимается связыванием файлов и сущностей. FileAttacher или можно например просто FileAttach?

первое

Т.е. всегда глаголом стараться называть?

ой, не глаголом))

в том смысле что зачастую сервисы получаются с окончанием ER

Manager, Logger, Uploader и т.п.

ну да

интересно как другие ещё называют

у меня есть Mailer как минимум)

а я таки добавляю суффикс. FileAttachService

мне так информативнее

а суффикс Service зачем?

по идее - имя должно говорить о том, чем сервис занимается. а тут получается, что сервис занимается тем, что является сервисом

Давно сюда не заходил. @mkusher, что вы там такое делаете с @fes0r'ом? Он раньше так не матерился.

Давно сюда не заходил. @mkusher, что вы там такое делаете с @fes0r'ом? Он раньше так не матерился.

у нас весело

по идее - имя должно говорить о том, чем сервис занимается. а тут получается, что сервис занимается тем, что является сервисом

Я раньше тоже пытался выразить черзе глалог, причем желатьлно не через -ER. но потом понял, что если создавать сервисы только там где они нужны, ничего страшного в суффиксе нет. Т.е я сервис использую или для аппликейшн сервисов - это по сути я создаю апи для контекста таким образом. или домэйн сервисы например RegistrationService - т.е выносить функцию register в модель юзера нелогично, т.к он не сам себя же регестрирует, плюс туда придется еще инджектить много всего

а вообще есть памятка, когда стоит выносить метод в сервис

Есть три характеристики служб: Операция, выполняемая службой, относится к концепции предметной области, которая не принадлежит ни одной из существующих сущностей; Операция выполняется над различными объектами модели предметной области; Операция не имеет состояния.

Давно сюда не заходил. @mkusher, что вы там такое делаете с @fes0r'ом? Он раньше так не матерился.

я раньше достаточно матерился на работе)

я раньше достаточно матерился на работе)

А без этого вообще можно программировать?)

А без этого вообще можно программировать?)

программировать - без проблем. Взаимодействовать с людьми - часто нет

А без этого вообще можно программировать?)

В одиночестве - можно.

Но недолго.

интересно как другие ещё называют

https://i.redd.it/rj8raf1riyny.png

https://i.redd.it/rj8raf1riyny.png

?

а я обычно так и называю =(

@yegor256 ты опять не разобрался с темой и опятть говоришь что кто-то не прав

Hey, a new post on my blog, about monolithic repositories, with a real example: https://www.yegor256.com/2018/09/05/monolithic-repositories.html

@yegor256 ты опять не разобрался с темой и опятть говоришь что кто-то не прав

Что опять случилось?

А то какие-то наезды в воздух, не надо так)

ну просто обычно ты стараешься с аргументами а тут - просто как будто бы вообще фантазии не хватило придумать что-то адекватное. Как если бы ты вообще не знал о чем говоришь

мы переживаем

вдруг творческий кризис

ну просто обычно ты стараешься с аргументами а тут - просто как будто бы вообще фантазии не хватило придумать что-то адекватное. Как если бы ты вообще не знал о чем говоришь

о чем ты? о статье последней?

да про монорепозитории

как же не знаю о чем говорю, если привел конкретный пример

показал плюсы и минусы

не теория, а чистая практика

Что бы сказать что все машины говно - недостаточно привести в пример ВАЗ

это не конкретный пример - это какая-то херня которая не имеет никакого отношения к монорепам

не теория, а чистая практика

практика людей которые не разобрались с проблематикой которую решатю монорепы

давай прямо там на блоге перейдем на личности) будет продуктивнее

Что бы сказать что все машины говно - недостаточно привести в пример ВАЗ

Нужно привести в пример проблемы, типа порча воздуха и т.п.

давай прямо там на блоге перейдем на личности) будет продуктивнее

не надо на личности переходить - там тебе в целом даже уже пояснили в комментах что обычно монорепы чуть по другому делают. И да - те проблемы о которых ты говоришь - в "практике" их нет

и да, монорепы это сложно и переход на оные должен быть обдуманным поступком, но! оно решает кучу проблем с синхронизацией инфраструктуры.

если у тебя там jquery плагин - то да у тебя нет проблемы для которых монорепы решение)

а потому глупо приводить это в пример. + моноепы и декомпозиция - оч странный наброс.

странно... у меня именно так все выглядит на практике

даже когды ты на SOLID накидывал было как-то интереснее (при том что там ты тоже как-то реальные проблемы, а они есть, заменил с большего на выдуманные)

либо сваливать много кода в одну репу, либо делать отдельные репы и модули

и я вижу в реальных проектах именно эту проблему -- люди валят все в одну кучу и в итоге это огромная свалка кода без каких либо границ и правил

вот я против этого

и призываю делать их мелкими, как только возможно

а всякие гуглы призывают делать наоборот

вот и конфликт мнений, который я проилюстрировал на микро примере

и я вижу в реальных проектах именно эту проблему -- люди валят все в одну кучу и в итоге это огромная свалка кода без каких либо границ и правил

лол

Это называется свалка кода, а не монореп

ты б хоть почитал как нормальные монорепы делаются и выглядят

и для чего

ну да, "это у нас не спагетти код, просто класс на 5000 строк"

ты б хоть почитал как нормальные монорепы делаются и выглядят

на личности давайте на блоге переходить, там смешнее будет)

либо сваливать много кода в одну репу, либо делать отдельные репы и модули

либо делать отдельные модули в одном репозитории

и я вижу в реальных проектах именно эту проблему -- люди валят все в одну кучу и в итоге это огромная свалка кода без каких либо границ и правил

отсутствие границ и правил - это проблема людей которые не проводят этих границ и не вводят правила. Это не вина монорепозиториев как концепта