а вот связи надо явно задть

и на момент записи 1 сущьности второй ещё може не быть

её может вообще никогда не случиться

ты сейчас описываешь тупо парсер сайтов

в план обхявили а тендер не провели или наоборот

ну как тупо

который просто скачивает данные и учитывает зависимости

ИИ там нет

который просто скачивает данные и учитывает зависимости

но там не каталог, сложная тсруктура

но да

главное - данные просто данные

но там не каталог, сложная тсруктура

ну суть то проста. Я не отрицаю что реализация может быть дико сложной

главное - данные просто данные

окей, дальше. Вот допустим ты скачал это дело и собрал в какой-нибудь там эластике

что дальше?

я не к томую. не к сложности

данные просто чёрный ящик

схемы рисуются в базу на лету

на данный момент - да, что с ними дальше происходит

те парсер во время работы сам себ схему расширяет

и по ним же строит автофильтры на любые поля

некоторые вещи мапятся, индексируются особым образом(скажем, для автокомплита)

то есть никакой именно бизнес логики нет - агрегатор данных, чисто инфраструктура?

есть конечно но не суть

поиск, карты

возвращаясь к сеттерам

поиск, карты

это не бизнес логика

причём в базе нет такой струткуры как город

это поиск и карты

поиск не бизнес логика? )))

ну окай

поиск не бизнес логика? )))

ммм.... только если ты гугл

и то нет

поиск - чисто инфраструктура

нет :)

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

есть правила? есть

есть принципы? есть

есть зависимости от предметной области? ещё как есть\

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

дыа

это и есть бизнес логика

я настаиваю

нет :)

раз у тебя данные это "черный ящик" - то о каких сущностях мы говорим? Их же нет. У тебя даже такие вещи как город это тупо строки "и потом разберемся"

раз у тебя данные это "черный ящик" - то о каких сущностях мы говорим? Их же нет. У тебя даже такие вещи как город это тупо строки "и потом разберемся"

чёрный ящик потому что большинство данных просто текст

не все

и фильтры(поиск) как раз смотрит - как они хранятся

не все

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

текст там или цифра

некоторые вещи мапятся, индексируются особым образом(скажем, для автокомплита)

вот здесь прочитай

те парсер во время работы сам себ схему расширяет

а вот про схему

оно достаточно умное чтобы не зраниться тупо

всё что можт быть автоматом распарсено(помечено как город) - индексируется иищется по правилам города

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

опять же это вообще не имеет смысл обсуждать :)

опять же это вообще не имеет смысл обсуждать :)

ну так ты как бы и не работаешь с сущностями, ты работаешь с данными

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

ну так ты как бы и не работаешь с сущностями, ты работаешь с данными

неее есть сущьность. в нём есть данные, технические поля(откуда когда) и спамленные вынесенные в корень на постоянный адрес name, суммы и тп

неее есть сущьность. в нём есть данные, технические поля(откуда когда) и спамленные вынесенные в корень на постоянный адрес name, суммы и тп

но логики в этой сущности нет

только данные

так?

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

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

для меня не очевидна связь между "1 докуммент" и "поставка в кучу городов"

но логики в этой сущности нет

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

для меня не очевидна связь между "1 докуммент" и "поставка в кучу городов"

ну вот так

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

ну то есть у тебя есть некий объект который все перечисленное умеет?

ну вот так

но это не точно?)

почему не точно

ERROR: S client not available

наоборот

почему не точно

потому что твое "точно" произростает из твоего вижена, а это значит что все субъективно и не точно)

в 1 тендере скажем для больницы могут быть одновременно поставка шприцов и поставка подгузников по всем больницам региона

разные сущьности

шприц для программиста сущьность прозначрная(данные) а для "оператора" - суть

шприц для программиста сущьность прозначрная(данные) а для "оператора" - суть

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

потому что твое "точно" произростает из твоего вижена, а это значит что все субъективно и не точно)

ты оспаниваешь мою точность в том что в тендере явно так прописано? ещё раз. разные источники

у тебя сущность означает буквально "сущность", то есть "штуки", что угодно

ты оспаниваешь мою точность в том что в тендере явно так прописано? ещё раз. разные источники

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

охох

потому что сеттеры это плохо? )

охох

предлагаешь мне наслово верить?)

нет предлагаю не углубляться в ненужные вещи

потому что сеттеры это плохо? )

не совсем. Ты уже выдал что ты про сеттеры в несколько другом контексте говоришь

это просто пример

скажем человек на сайте меняет форму в 50 полей

это просто пример

не показательный пример

не важно сколько шагов он сделал это просто данные

если на эту же форму можно изменить только 5 полей потому что через апи ты каждое поле предложишь вынести в отдельный экшен? )

не важно сколько шагов он сделал это просто данные

а может быть ему и не надо было эти 50 полей менять

конечно нет )

ты не понял

если вернутся к изначльной не моей заморочке сет плох тем что делает не всё сразу

я еще раз поясню почему сеттеры это не очень хорошая идея: ты когда юзаешь сеттеры для тебя нормально, 10 полей у формы, кнопка просто или 100. Тебе просто пофигу. Это просто данные. И ты приводишь пример где работаешь с "тупо данными", где у тебя нет сущности "тендер" как объекта (насколько я понимаю) а есть просто модель данных и все. Все остальное - пайплайн, какие-то "функции" которые занимаются пред/пост обработкой. Тут нет "сеттеров" в том смысле о котором я говорю.

бывает что всё сразу тупо нет под рукой

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

appendVO а не forech + setEachInput

в плодь до того что косвенно это все влияет на построение UI

appendVO а не forech + setEachInput

не путай имутабельность и отсутствие сеттеров

те не append

можно по разному делать

те не append

то есть не упрощай)