докинь еще какой-нибудь шаг в промежутке, до меня не дошло пока

сущность как просто тип

как набор функций работающих с некой структурой данных

что бы ты мог в рантайме поведение подменять

ну мол то о чем DCI

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

ну то есть в PHP это все выглядит неестественно....

а потому популярность имеют анемичные модели и сервисы менеджеры (я лишь предлагаю сохранить "принадлежность" стэйта тому где логика)

ну короч я ж говорю - мысль сырая....

ну да, данные и роли

> "принадлежность" стэйта тому где логика скорее наоборот

логика вяжется к стейту

пока думаю что максимально близко эта мысль раскрыта в DCI но не уверен еще на 100%.... просто единственный аспект о котором я мало пока думал - различия между статическим и динамическим миром (ранаймом и кодом)

> Я вот например хочу использовать симфони, как MVC, а для этого надо самому реализовать Model, как это сделать лучше всего? тут надо разобраться что для тебя MVC)) то MVC которое по Тургве или то MVC которое из рельсов? В руби скажем у тебя есть миксины на уровне языка что уже позволяет чуть по другому делать. В PHP у тебя ситуация отличается увы

очень сложна) Начну с более простого, у меня сейчас доктрина прямо из контроллеров используется, хочу всю эту логику переместить в сервисы и инжектить эти сервисы в контроллеры. Как лучше всего это организовать? Создать директорию Model и туда класть классы с такими же именами, как сущности? Или создать директорию Service и туда пихать все сервисы? Тогда немного нелогично получается, потому как в четвертой симфони там всё сервисы. Или может для каждой сущности создавать UserManager, PostManager и т.д. в зависимости от имени сущности? Или вообще имена не привязывать жестко к именам сущностей? Что почитать? Какие шаблоны проектирования учить?

логика вяжется к стейту

да, но это не "сервис менеджер" в классическом для симфони варианте)

да, но это не "сервис менеджер" в классическом для симфони варианте)

ну да, я про dci вариант

очень сложна) Начну с более простого, у меня сейчас доктрина прямо из контроллеров используется, хочу всю эту логику переместить в сервисы и инжектить эти сервисы в контроллеры. Как лучше всего это организовать? Создать директорию Model и туда класть классы с такими же именами, как сущности? Или создать директорию Service и туда пихать все сервисы? Тогда немного нелогично получается, потому как в четвертой симфони там всё сервисы. Или может для каждой сущности создавать UserManager, PostManager и т.д. в зависимости от имени сущности? Или вообще имена не привязывать жестко к именам сущностей? Что почитать? Какие шаблоны проектирования учить?

1. зачем в сервисы, если можно в сущности?

очень сложна) Начну с более простого, у меня сейчас доктрина прямо из контроллеров используется, хочу всю эту логику переместить в сервисы и инжектить эти сервисы в контроллеры. Как лучше всего это организовать? Создать директорию Model и туда класть классы с такими же именами, как сущности? Или создать директорию Service и туда пихать все сервисы? Тогда немного нелогично получается, потому как в четвертой симфони там всё сервисы. Или может для каждой сущности создавать UserManager, PostManager и т.д. в зависимости от имени сущности? Или вообще имена не привязывать жестко к именам сущностей? Что почитать? Какие шаблоны проектирования учить?

почитай про cohesion

ты сейчас логический кохижен описал

я могу кинуть видос, но он не совсем про это главная его мысль: imperative shell, functional core

1. зачем в сервисы, если можно в сущности?

Потому что сущности это не модели, а persistence layer, контроллеры не должны работать напрямую с доктриной, они не должны знать, как данные сохраняются

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

Потому что сущности это не модели, а persistence layer, контроллеры не должны работать напрямую с доктриной, они не должны знать, как данные сохраняются

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

Потому что сущности это не модели, а persistence layer, контроллеры не должны работать напрямую с доктриной, они не должны знать, как данные сохраняются

а я не говорю контроллерам работать с доктриной

а не как persistence

p.s. если ты готов мириться с ограничениями вида "не может быть односторонних one-to-many"

просто логика свойственна сущности, не менеджерам

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

Да пошли они к черту)

Да пошли они к черту)

не я о том что бы уменьшить количество слоев

слои говно

их надо очень осторожно вводить

полностью понимая что они тебе дают

я например использую сущности в контроллерах и мне норм))

потому что у меня в таком варианте контроллер всеравно на 2-3 строчки кода

public function someAction(SomeEntity $something, User $currentUser) { $something->doSomethingAs($currentUser); $this->flushChanges(); }

главное что бы в контроллерах не появлались if-ы

потому что у меня в таком варианте контроллер всеравно на 2-3 строчки кода

А у меня много логики в контроллерах выходит, контроллер для менеджмента графов, и там много вычислений получается, когдао ты узлы или целые ветки переносишь с одного узла на другой, толстые контроллеры в общем получаются

А у меня много логики в контроллерах выходит, контроллер для менеджмента графов, и там много вычислений получается, когдао ты узлы или целые ветки переносишь с одного узла на другой, толстые контроллеры в общем получаются

о, графы.... а можешь чуть рассказать что делаешь?

Да пошли они к черту)

в целом - никого не слушай, даже меня))) ну или лучше сказать никому не верь

https://telegram.veesecurity.com/

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

пока что на работе это помогло. хотя наверное скоро и это потухнет )

а встроенное прокси?

не знаю

ок, бандла нет. Там просто используют doctrine аннотации. Но это не мешает делить апи, указывая путь к папке для генерации доков. В примере middle-office это один проект

код покажи

о, графы.... а можешь чуть рассказать что делаешь?

На самом деле я просто хотел сделать иерархию литературных жанров (о чем я тут говорил несколько дней назад), но у меня требование такое, что один поджанр может входить одновременно в несколько наджанров, то есть иметь несколько родителей, стало быть, это не иерархия уже, а направленный ацикличный граф (Directed Acyclic Graph). Так как SQL не самое удобное хранилище для деревьев, пришлось немного поломать голову, как лучше всего это все хранить, но решение в итоге я нашел

На самом деле я просто хотел сделать иерархию литературных жанров (о чем я тут говорил несколько дней назад), но у меня требование такое, что один поджанр может входить одновременно в несколько наджанров, то есть иметь несколько родителей, стало быть, это не иерархия уже, а направленный ацикличный граф (Directed Acyclic Graph). Так как SQL не самое удобное хранилище для деревьев, пришлось немного поломать голову, как лучше всего это все хранить, но решение в итоге я нашел

neo4j? orientdb?)

neo4j? orientdb?)

Не хочу смешивать различные хранилища, у меня все в мускуле хранится.

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

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

Да зачем мне для небольшой таблицы использовать отдельное хранилище. Я даже не слышал доселе об OrientDB и neo4j, сейчас все это изучать у меня времени нет. Мне еще elasticsearch прикручивать надо будет, потом надо будет заставлять работать это все вместе.

@fes0r привет

Да зачем мне для небольшой таблицы использовать отдельное хранилище. Я даже не слышал доселе об OrientDB и neo4j, сейчас все это изучать у меня времени нет. Мне еще elasticsearch прикручивать надо будет, потом надо будет заставлять работать это все вместе.

а эластика тебе зачем?

а встроенное прокси?

телега заметно лагает, файлы не подгружает, и мелькает постоянно что идет соединение

Да зачем мне для небольшой таблицы использовать отдельное хранилище. Я даже не слышал доселе об OrientDB и neo4j, сейчас все это изучать у меня времени нет. Мне еще elasticsearch прикручивать надо будет, потом надо будет заставлять работать это все вместе.

ну логично графы хранить графами)) это проще и т.д. да и по сложности mysql побольше будет

@fes0r привет

привет

ты же пишешь апишки, емнип, чем документируешь?

или ты сначала документация потом апи, и не юзаешь автогенерацию документации?

сначала доки и потом реализация

а эластика тебе зачем?

будут сложные запросы, умный живой поиск и надо, чтобы это было быстро

что бы можно было распаралелить разработку

ясн

будут сложные запросы, умный живой поиск и надо, чтобы это было быстро

ну ладно, я не настолько шарю в mysql.... я больше к тому что тот же orientdb или neo4j интегрировать в проект проще чем эластику, учитывая что большую часть того что мне эластика дает я могу делать на postgresql. С эластикой я б игрался на реально больших объекмах... ну или специфичных штуках (например мне надо было класстеризацию мутить)

просто графы в виде реляций это всегда будет боль и придется денормализовать по итогу

а поскольку mysql хоть и умеет json но плоха с построением индексов - то всеравно будут беды

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

ERROR: S client not available

просто графы в виде реляций это всегда будет боль и придется денормализовать по итогу

У меня заранее определена глубина вложенности в 6 уровней, и есть примерное представление о количестве узлов, скажем 500. Думаю для такого маленького дерева не страшна реализация в mysql. В данный момент у меня такая реализация: Таблица Genre, с полями id и name. И таблица GenreEdge (раньше называлась GenreHierarchy) с полями: id, level1, level2, level3, level4, level5, level6. Каждая строка этой таблицы хранит уникальный путь (ребро графа, отсюда и edge) от родителя к последнему предку. Раньше была реализация посложнее, расчитанная на теоретическ бесконечный уровень вложенности и очень быструю выборку, но потом я зае**лся и плюнул на все, решил сделать более простой вариант, все равно граф небольшой, какая разница.

А мучился я над первой реализацией, потому что хотел сделать что-то уникальное, не привязанное к моему проекту, в виде библиотеки

У меня заранее определена глубина вложенности в 6 уровней, и есть примерное представление о количестве узлов, скажем 500. Думаю для такого маленького дерева не страшна реализация в mysql. В данный момент у меня такая реализация: Таблица Genre, с полями id и name. И таблица GenreEdge (раньше называлась GenreHierarchy) с полями: id, level1, level2, level3, level4, level5, level6. Каждая строка этой таблицы хранит уникальный путь (ребро графа, отсюда и edge) от родителя к последнему предку. Раньше была реализация посложнее, расчитанная на теоретическ бесконечный уровень вложенности и очень быструю выборку, но потом я зае**лся и плюнул на все, решил сделать более простой вариант, все равно граф небольшой, какая разница.

для такого маленького дерева - да

а еще если оно редко меняется то вообще пофигу

добрый день возник вопрос в отдельном сервисе выполняю приходование товара обновляю одну таблицу(таб С) и создаю новые записи в 2 других (таб А, таб Б), причем в одной из новых таблиц(таб Б) данные зависят только от SN товара, остальные параметры постоянны. Очень хочется создание данных для этой таблички(таб Б) вынести в отдельный метод, т.е. на один товар создается 8 записей (для таб Б). Обновление/создание записей (таб А, Б, С) планировал реализовать в одной транзакции, т.е. это по бизнес логике одна операция, вопрос если (для таб Б) создание записей вынести в отдельный метод то как быть с транзакцией? получается (таб Б) будет отделена от транзакции, можно это как то исправить?

а еще если оно редко меняется то вообще пофигу

Редко, но все же меняться будет. Представь, ты создал дерево из 150 узлов под категорией Роман, а потом это дерево надо скопировать в категорию Рассказ. Тут и понадобится операция копирования всего дерева. Раньше в моей таблице каждый узел указывал на всех своих родителей и хранил инфу об отдаленности от своего родителя, пример: id | child | parent | level 0 | 5 | 4 | 1 1 | 5 | 3 | 2 2 | 5 | 2 | 3 3 | 5 | 1 | 4 такая таблица достаточна, для хранения иерархий с любым уровнем вложенности, предки могут иметь сколько угодно родителей и выборка при этом очень быстрая. Но у меня возникли проблемы с валидацией, особенно когда перемещаются целые ветки (меремещение в самого себя, перемещение в тоже самое место, копирование ветки и прочее и прочее). Но если бы я закончил, можно было бы опубликовать все это

Как библиотеку

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

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

тебе нужно пагинировать основную таблицу, или и её, и связи?

пагинация на основную

в принципе дистинкт он может решить часть проблем, но не все

group by?

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

чёт сложно

SELECT task.* FROM task LEFT JOIN task_entry ON task.id = task_entry.task_id GROUP BY task.id;

где много?

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

++ каждое поле приходится вписывать, раньше (на старых версиях мускула) таких проблем не было вроде

++ каждое поле приходится вписывать, раньше (на старых версиях мускула) таких проблем не было вроде

Просто в sql_mode по умолчанию включена опция ONLY_FULL_GROUP_BY

вопрос снимается, доктрина оказалась гораздо умнее меня)) просто dql джоины прикрутить нужно было и убрать у связей жадную загрузку

какой айсикью у доктрины?

... и эту доктрину звали Альберт Эйнштейн

... эту девочку звали Доктрина

Кто нибудь использовал паттерн Command Bus в своих симфони проектах?

Кто нибудь использовал паттерн Command Bus в своих симфони проектах?

+

да, мораль шин команд - они тебе не нужны покуда у тебя нет необходимости в асинхронной обработке действий

ну либо тебе надо тупо ограничить разработчиков что бы те в операциях записи не возвращались значений

да, мораль шин команд - они тебе не нужны покуда у тебя нет необходимости в асинхронной обработке действий

и ты не паришься, где писать флаш)

+

И что скажешь плохого/хорошего?

И что скажешь плохого/хорошего?

it depends

и ты не паришься, где писать флаш)

ну это единственный плюс - возможность навешивать мидлвары

НО! ты как бы можешь и через сервисы это делать спокойно))

прокси там, декораторы, AOP