Здравствуйте, ·, Вы писали:

·>Т.е. может быть придётся генерировать строку вида "...in ('id1', 'id2', ..., 'id1000')" вместо использования ?-параметров и байдинга.
Не "может быть", а совершенно точно так и придётся. Для этого сценария ? — параметры и байндинг будут только портить производительность.

Здравствуйте, zelenprog, Вы писали:


Z>>>Делаю программу, стараюсь применять DDD и "правильную" архитектуру.
G>>Правильная это та где работает быстрее, кода меньше и плотность ошибок ниже.

Z>Не согласен.
реальности плевать на твое мнение.

Z>Насчет "кода меньше" — это вообще в корне неверно. Объем кода ничего не говорит о качестве программы.
Очень наивное заблуждение.
Количество ошибок на 1000 строк величина постоянная, почти не зависит от проекта и даже от языка. То есть чем больше строк, тем больше ошибок в программе.
Кроме того количество строк кода напрямую влияет на стоимость написания и модификации программы.
То есть при равном функционале чем больше строк, тем программа дороже и содержит больше багов.


Z>Насчет "плотность ошибок ниже" — с этим согласен — это я бы поставил на первое место, именно в этом и есть цель архитектуры. С кривой архитектурой ошибок будет больше.
Плотность как раз величина почти постоянная. А само количество ошибок напрямую зависит количества строк кода.

Z>Только у тебя причинно-следственная связь перепутана.
Z>Продумав и применив правильную архитектуру — как следствие получаем меньше ошибок.
Z>Если мы каким-то загадочным образом написали код без ошибок — это не значит, что он построен по правильной архитектуре.
Снова повторяешь наивное заблуждение, что есть способ уменьшить плотность ошибок какой-то "архитектурой".

Z>Насчет "работает быстрее" — это на следующем месте по важности.
Z>Но если нарушение архитектуры и усложнение кода приводит к незначительному увеличению производительности, то лучше от такого кода отказаться.
Почему лучше? В чем же ценность архитектуры в итоге?

G>>Я правильно понимаю, что все приседания чтобы не писать .Include ? зачем? какие характеристики программы это улучшит?

Z>У меня нету .Include.
Z>Есть "голые" sql-запросы, которые я сам пишу в методах класса Репозитория.
Тогда сделай запросы, которые вернут сразу все необходимые данные в одном методе репозитария.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ·, Вы писали:

S>·>Т.е. может быть придётся генерировать строку вида "...in ('id1', 'id2', ..., 'id1000')" вместо использования ?-параметров и байдинга.
S>Не "может быть", а совершенно точно так и придётся. Для этого сценария ? — параметры и байндинг будут только портить производительность.

Сейчас модно передавать массив в качестве параметра (json для MSSQL)

Здравствуйте, Sinclair, Вы писали:

S>- в варианте с временной таблицей данные едут между первым запросом и вторым через дисковый кеш.

Почему не через память? Движок не может в памяти хранить временную таблицу?

Здравствуйте, Sharov, Вы писали:
S>Почему не через память? Движок не может в памяти хранить временную таблицу?
Может, но как он об этом узнает?

Здравствуйте, gandjustas, Вы писали:

G>Сейчас модно передавать массив в качестве параметра (json для MSSQL)
Это применимо там, где драйвер такое умеет. Постгре или там MS SQL — без вопросов, Оракл — наверняка, хоть я точно не знаю. sqlite — не-а. Не настолько развитая система типов.
Если посмотреть на SO, то там всё сводится к советам "делайте .join(',') и подставляйте текст" и "работайте через временную таблицу".

Q>А в чем проблема? Вытаскиваете нужные Вам сущности из репозитория в месте с TovarEntity.

Ну... я писал-писал длиннющее сообщение, в котором описал проблему.
Неужели по моему тексту не ясно в чем проблема?

Кратко напишу еще раз.
Каждый Репозиторий должен выдать список "своих" сущностей, с которыми он "умеет" работать.
Два Репозитория (Аналоги и Упаковки) используют в качестве фильтра отбора один и тот же список товаров.
Отбор аналогов и упаковок по списку товаров выполняется на "физическом" уровне с помощью sql-запроса, который в качестве условия фильтра использует временную таблицу товаров-"владельцев".

Получается, для обоих Репозиториев (Аналогов и Упаковок) нужна одна и та же временная таблица.
Значит, эту временную таблицу со списком товаров должен какой-то программный код "подготовить" заранее, перед вызовом методов Репозиториев.

Так как "манипулированием" методов Репозиториев занимается слой бизнес-операций, значит этот код должен располагаться в слое бизнес-операций.
Однако, временная таблица — это низкоуровневое понятие, связанное с реализацией взаимодействия с базой данных, и понятие временной таблицы не доступно на уровне бизнес-операций.
В этом и заключается противоречие — проблема: бизнес-слой вроде бы должен создать временную таблицу, но с точки зрения "теории" не должен ничего знать про временные таблицы.

Здравствуйте, zelenprog, Вы писали:


S>>Ошибка уже здесь. Временная таблица — это очень плохое решение:

Z>Я пока пользуюсь sqlite.
Z>Как мне кажется, там кроме временных таблиц ничего другого нельзя применить.

Там есть в поставке по умолчанию `carray`.
Можно просто "отдать" массив с помощью "bind", и в запросе можно написать `IN carray(param)`
https://www.sqlite.org/carray.html

Здравствуйте, Sinclair, Вы писали:

S>Это применимо там, где драйвер такое умеет. Постгре или там MS SQL — без вопросов, Оракл — наверняка, хоть я точно не знаю. sqlite — не-а. Не настолько развитая система типов.
Снимаю своё возражение в свете вот этого.