Допустимо объявлять свойства класса с большим набором данных?

ООП вообще никак такие вещи не регулирует. Это правило хорошего тона, чтобы сущность помещалась на один экран.

Как лучше задать список фильтров?

Лучше задать статичным свойством, если это возможно, и засунуть в конец исходника - чтобы не мешало читабельности класса.

Нормально избегать, но возможно не всегда. Например, в языках общего назначения «модно» абстрагироваться от всего... а потом одепты приходят в облачный стек где база встроенная, заменить ее нельзя, запросы в коде это нормально, транзакция в UI занимает N секунд энивей, все прослойки милые сердцу ООПщиков жрут весьма ограниченную облаком память (десяток мегабайт на юзера). Но да, можно генерить длинные запросы для бэкграунд-воркеров и даже «повар-юзерам»(операторам, админам) показывать результат конкатенации фильтров для каких-нибудь тяжелых батчей. В классе с т.з. программиста это тупо строка, почти без SQL (там какой-нибудь дефолтный шаблон, достаточно короткий и читабельный), так что в коде в общем ничего и не загромождается.

А зачем оно паблик? Может сделать приватом и получать данные через метод?

Как лучше задать список фильтров?

кажется обычно такое делают бильдером, т.е. ты делаешь отдельный класс который конструирует владеемый им объект с фильтрами через вызов сеттеров возвращающих инстанс этого же бильдера (this), а метод build возвращает уже сам требуемый объект

$filter = new FilterBuilder()
  ->byUserType(...)
  ->byFoo(...)
  ->byBar(...)
  ->build();

Если у тебя в данных sql портки - это не нормально и черевато всякими иньекциями и пр. косяками. Если не хочешь иметь дело с мразотными орм, выноси всю работу с sql куда-нибудь отдельно и собирай их каким-нибудь querybuilder'ом по передаваемой структуре. И там если клеешь sql, проверяй 10 раз, что клеешь.

О, фильтры! Моя любимая тема для стратегий. Т.к. какие-то фильтры тривиальные без параметров, другие параметризованы разным количеством параметров разных типов, и если всё это загонять в единую структуру для data-driven, получится развесистая динамически-типизированная union-подобная хрень – причём что в объявлении структуры, что в коде, с ней работающем. А если каждый фильтр сделать подклассом стратегии (параметры фильтра через конструктор, плюс virtual apply()) – то прямо тут же счастье и наступает, и волосы становятся чистыми и шелковистыми.

Похапе… Без ORM… Ненормально

Вынеси в конфиг

Варианта с выносом всей портянки SQL в процедуру БД ещё не было. Вот - предлагаю.

В клиенте только флажки расставить и передать в процедуру. Она там сама разберется куда и как их применить в код SQL.

Я бы switch сделал вместо мапы.

Чем свитч на дохера кейсов лучше мапы?

А чем таки orm мразотные? Мсье любитель писать mappings, filtering & pagination вручную?

Да хз, как-то удобней, что-ли. Мапа она просто мапа и всё. А в свиче может там параметр какой-то передать можно будет. Или растащить его разные куски по разным функциям.

Мсье любитель писать mappings, filtering & pagination вручную?

Уеб-макака чтоли?

А чем таки orm мразотные?

Мразотные по той простой причине, что не позволяют правильно и полноценно использовать все возможности конкретной СУБД и предоставленных для этой цели специализированных драйверов. Иногда это приводит не просто к медленной, а просто к катастрофически медленной работе приложения - типа, вместо одной минуты три часа :)

Медленные приложения получаются не от orm, которые в свою очередь пишутся действительно гениальными людьми и оптимизированы по самое немогу, они получаются от надмозглых погромистов, которые начитались «банды 4х» и всяких «клин кодов» и городят теперь фабрики фабрик и суют юзер дефаинд классы в ключи хешмапов, что они отрабатывают не за 1наносекунду, а за 1 секунду, и потом еще тебе с круглыми глазами доказывают, что никогда оно им не мешало.

А orm няшки. Любой, кто писал вебню на спринге с jpa и без, меня поймет.

upd: про драйвера вообще не понял. Оно у тебя с orm на святом духе работает?

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

Не смешите людей )) Откуда такая «святая» вера в то, что все широкоиспользуемое является правильным и оптимальным и написано «гениальными» людьми? Оптимизированными «по самое немогу» ORM-ки не могут быть по определению, поскольку для оптимизации нужно знать вполне конкретную схему БД, чего у создателя ORM нет в принципе.

Как вообще можно оптимально работать с БД, не имея представления о том, что вытворяет «гениальная» ORM у себя под капотом?

ORM-ки можно использовать только на низкозагруженных СУБД-шках с крайне небольшим объемом данных, где можно вообще наплевать на то, каким конкретно образом извлекаются и обновляются данные. Ну т.е. это для ленивых программистов, которым наплевать на скорость работы приложения. Причем, как я уже выше сказал, падение скорости может быть просто фатальным.

ORM просто генерирует запросы. Эти запросы могут быть эффективными, могут быть нет. Задача разработчика - при написании/отладке запроса, посмотреть на сгенерированный SQL, чтобы там не было очевидной дичи.

Понятно, что это не серебрянная пуля, но ORM очень сильно облегчает жизнь и ускоряет разработку. И в высоконагруженных системах они используются, потому что там тоже время разработки, поддерживаемость и переиспользуемость кода важны. Возможно, даже более важны, чем на 5-10% большая производительность голых запросов. Впрочем, даже это никто не ещё не доказал (что голый SQL всегда быстрее). Зато он совершенно точно не способствует ясности кода и возможности его повторного использования.

В ООП допустимо объявлять любые property. Пусть даже владеющие ссылки на объект. Или коллекции объектов. Как архитектуру спроектируешь, так и будет.

Задача разработчика - при написании/отладке запроса, посмотреть на сгенерированный SQL, чтобы там не было очевидной дичи.

Ну посмотрели, увидели эту самую дичь - и что дальше? Исправлять-то как? Это же не вы эту дичь нагородили, а ORM-ка.

поддерживаемость и переиспользуемость кода …

Это дело гораздо лучше и оптимальнее обеспечивается наличием в коде приложения конкретного уровня абстракции, рассчитанного на вполне конкретную бизнес-логику. Связываться с ORM просто по этой причине - это, прямо скажем, не очень разумно.

Исправлять-то как? Это же не вы эту дичь нагородили, а ORM-ка.

Любой ORM позволяет влиять на SQL выхлоп в достаточно широких пределах.

Я периодически ставил над собой эксперименты, когда было время и желание, и переписывал монструозные SQL простыни в своих проектах на чистый ORM. Иногда приходилось упарываться несколько дней, но в итоге всегда получалось получить запрос «идентичный натуральному», возможно +1 джойн или ещё какая-нибудь незначительная мелочь.

Это дело гораздо лучше и оптимальнее обеспечивается наличием в коде приложения конкретного уровня абстракции, рассчитанного на вполне конкретную бизнес-логику. Связываться с ORM просто по этой причине - это, прямо скажем, не очень разумно.

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

но в итоге всегда получалось получить запрос «идентичный натуральному», возможно +1 джойн или ещё какая-нибудь незначительная мелочь.

Ну это если «мыслить» в пределах одного конкретного запроса. Но ORM-ка может нагородить кучу запросов там, где при SQL-мышлении нужно выполнить всего один-два.

Ну а возьмем, к примеру MongoDB. Там использовать какую-нибудь универсальную ORM-ку - это вообще изначальная дичь.

nativeQuery? Не, не слышал. ORM спасает тебя от написания километров бойлерплейта, а не логику за тебя пишет. Какие запросы оно генерирует, когда не пишешь их руками, оно тоже выводит в дебаг, гадать на кофейной гуще не надо.

У тебя просто слишком мало (либо нет вообще) опыта работы с orm.

У меня есть UI, где юзер выбирает фильтры

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

в некотором классе есть поле

и этих фильтров много, около 50

Это нормально или лучше избегать такой практики

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

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

В том-то и дело, что ORM - это весьма неестественная абстракция для SQL СУБД-шек, и NoSQL тоже. Поэтому логику отображения объектов в записи SQL-таблиц она за тебя пишет - причем такую, что заведомо не всегда возможно оптимизировать ручками.

У тебя просто слишком мало (либо нет вообще) опыта работы с orm.

Совершенно верно - и это потому, что я отчетливо представляю, к каким неприятностям может привести использование ORM при сопровождении ПО и необходимости внесения каких-либо изменений-дополнений в схему базы. Ну и наблюдал проблемы печальный опыт других юзеров ORM )

Впрочем, не буду убеждать - каждому своё.

Впрочем, не буду убеждать - каждому своё.

В интернетах с людьми хоть поспорить/поубеждать можно.

Хуже, когда новый тех.дир верует в ORM и прочий Питон.

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

Так это и в мапе можно. Можно еще мапу растащить на n модулей.

Тем, что они не делают нормально ничего из вышеперечисленного.

mappings

В тайпскрипте вон, entity мутабельные. Пресист делает и херит её.

filtering

Как они там делают выборки по массиву ид, not null, not in и пр. не дефолтные вещи? Sql запросом, м?

pagination

И что они там все умеют нормально делать фетч из запроса/стрима/курсора в общем случае или надо допиливать под целевую бд? Или там тупо лимит, чтобы не заморачиваться?

ORM спасает тебя от написания километров бойлерплейта

Не спасёт. От бойлерплейта спасёт тебя твоя либа под твои задачи. ОРМ покроет 90% того, что нужно, под остальное будет делать костыли убогие, по объему которые будут на порядок больше того, что пытался сэкономить.

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

(любым студентом на за лабу)

Любой ORM позволяет влиять на SQL выхлоп в достаточно широких пределах.

У тебя настоящих запросов просто нету. А максимум, что есть inner/left join.

Допустимо объявлять свойства класса с большим набором данных?

Похоже на «Можно ли на костылях пробежать стометровку за десять секунд?».

Все зависит от костылей. А ну они там на пневматике?

ТС вас не поймёт (хотя вы правы).

Помогу немного ТС.
Без «пневматики» в разработке далеко не уедешь.

Еще один не знает про native query. Твои посты похожи на php/python-o проблемы. Возьми уже нормальный java стек и не мучайся.

Похапе… Без ORM… Ненормально

А слабо обосновать, что похапэ с ORM – это нормально?

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

Уже двое больных с идеей конфиг файла. А давайте вообще загоним весь код в конфиг файл, а вместо кода впилим интерпретатор этого конфиг файла? Тогда можно будет менять конфиг файл, не меняя кода! …Так, стоп, у ТС-а же и так уже пэхэпэ.

Похапэ это вообще - можна нинада?

Гы, нет уж! Я тоже начал было писать с этого же, но во-первых, у ТС-а похапэ – это данность, а в-главных, мне очень захотелось послушать аргументацию адепта использования ORM на динамически-типизированном языке. :-P

У ТС две больные данности - похапэ и нету ORM. Обе надо лечить, правда, если начать с ORM то там и закончится. А чем динамически типизированный язык мешает? Такой высер как Sequelize же существует, хехе, я здесь живу

Ну в нормальных приложениях именно так и делают (я даже участвую в разработке таких). Даже без учета ПХП это рациональное решение, а если это какой компилируемый язык так и подавно нужно такое делать. Если у вас есть предложение получше - предлагайте. Но вероятно у вас их нет (как и опыта), вы только набрасываете.

native query это от безысходности, а не что-то, чем можно гордиться и советовать. Ибо хоронит всю концепцию ORM.

Если так думать, то ORM действительно инвалид. Ибо ничего кроме простейших запросов не может. Не всегда имеется возможность загружать тонны данных в память и любой приличный айтишник все вычисления будет максимально спихивать на sql сервер.

Для меня ORM это способ экономии времени и денег заказчика на бойлерплейт.

ORM дерьмо и без него тоже плохо. Не знаю, что тут делать. Я считаю, что язык должен хорошо сочетаться с SQL, HTTP, JSON, может быть даже с HTML. Но я таких пока не видел, лишь зачатки в виде pl/sql, JS, JSX.