Роман Вакульчик: да, в этом случае индекс не поможет.... тогда самый быстрый вариант на самом деле хранить весь JSON в памяти и рекурсивно его обходить постоянно. Можно это дело распаралелить, можно еще кучу всего придумать... но не зная задачи (что за JSON, вложенность, что содержит и что ищем) больше сказать ничего не могу.
Если данных реально 3 килобайта - то можно просто решение в лоб. На таких объемах данных разницы вы не сильно почувствуете.
Алексей Ситников: Вообще в DDD есть понятие сущности, и в контексте доктрины оно предполагалось что будет именно так. По сути плюс доктрины в том, что она вас никак вообще не ограничивает в плане организации моделей. То есть вы проектируете не базу данных а модель и взаимодействие объектов друг с другом. То что у большинства модель это поля и геттеры/сеттеры - это плохо.
Алексей Ситников: если что, в последней версии доктрины есть новый тип связи - @embedded - который позволяет вклинивать объекты-значения в линейную структуру таблицы. Так же основная соль моделей - они в принципе не должны иметь возможность стать не валидными. Поэтому я потихоньку вообще отхожу от валидации моделей и больше занимаюсь валидацией запросов или данных. Это сильно упрощает код.
В Symfony вообще нет такой вещи как сущности. Они есть в доктрине. И это круто что там нет никаких парент классов и т.д. потому что в этом случае можно использовать старые добрые классы для реализации жирных моделей и т.д.
Грубо говоря, у нас есть сущности, которые представляю собой элементы бизнес логики, и объекты-значения, которые описывают состояние модели. То есть в вашем примере у меня был бы класс Product который представлял бы сущность, и одну часть его состояния (price) описывал бы отдельный объект-значение ProductPrice, который включал бы в себя два полня, собственно стоимость (целым числом) и валюту. И именно этот объект использовала бы система. Отдельно был бы сервис CurrencyExchanger или что-то в этом духе, который бы брал этот ProductPrice (а лучше завязать на интерфейс PriceValue или что-то в этом духе) и возвращал бы новое значение. Причем все это скорее всего мне нужно исключительно при формировании вывода пользователю. То есть это уже слой представления. И репозиторий для ExchangeRate у меня возможно не к базе бы обращался а к какой-то апишке, естественно с кешированием в реддис.
Алексей Ситников: тип того, чтолько вот репозитории от сущностей не зависят как бы.... ну да не суть.
Вообще к вопросу о бизнес логике и репозиториях... в идеале вся основная бизнес логика должна быть вынесена в модель, и оперировать в рамках запроса и выполнении каких-то бизнес задач нужно через эту самую сущность. Пусть она уже сама меняет связанные с ней сущности и т.д. У вас для этого есть unit-of-work, который разруливает состояние загруженных моделей.
Алексей Ситников: Ну представьте себе такую ситуацию. Сегодня вы юзаете доктрину, а завтра этот же репозиторий будет уже даже не с базой работать а с чем другим. В этом случае мы просто подменяем реализацию конкретного сервиса и больше ничего не трогаем в проекте - интерфейс сохраняется, код продолжает работать... Ну и тестами покрыть проще - нужно замокать только репозиторий а не entity manager.
Pavel Yakovlev: да, именно, виртуалочки. Не вижу в этом никаких проблем. Есть Modern IE - удобненько, поднял нужную тебе версию IE и радуешься. Зато со средствами разработки все намного лучше. Да и в WEB фотошоп уже не царствует, есть ПО типа Sketch и т.д. которого нет под винду. Лично мне с этой штукой больше понравилось работать.
Евгений: а я бы порекомендовал в таком случае Крэйга Лармана почитать еще (про GRASP). Это более обобщенные штуки и они хорошо проецируются на различные языки. Но в целом согласен.
NikesDark: Java, C#, Go, D, Rust... это развиваться. И почему люди думают что что бы развиваться надо именно сменить язык а не просто добавить еще один. Язык лишь инструмент.
Японский Городовой: jpg можно уже на сервере сделать если так душе хочется. Но в целом проблем с экспортом в jpg нет. Проблема с поддержкой в браузерах - это да.
Японский Городовой: думаете я просто так про 2015-ый говорю? Прошли те времена, когда делать что-то на клиенте медленне на сервере настолько, что можно так сильно напрягать сеть. Есть конечно же исключения, но в целом...
Японский Городовой:
1) с WebGL или canvas такие вещи можно прямо на GPU делать, это будет даже быстрее чем на сервере. Или вы думаете что я предлагаю вам манипулировать напрямую пикселями? Так же как и в случае с сервером - просто говорим сишной библиотеке, которая есть в браузере, куда что скопировать и т.д.
2) мы не гоняем трафик туда-сюда. Повышаем отзывчивости системы (не нужно на каждый чих переотправлять данные на сервак).
capable: я не говорил про "не подойдет", просто "предпочтительнее". Проще для взаимодействия дизайнер - разработчик. Точно так же как мак более чем норм для backend, просто о некоторых радостях жизни придется забыть.
Если данных реально 3 килобайта - то можно просто решение в лоб. На таких объемах данных разницы вы не сильно почувствуете.