Цитата:
Сообщение от
mazzy
Раз возникают такие технические промежуточные view, то возникает задача выбора между ними, комбинирования таких view.
другими словами, нужен класс, который бы отвечал за бизнес-сущность
Я не очень понимаю, к чему ты ведёшь. Вероятно, это всё-таки не мне был ответ. Если ты хочешь поговорить о data entities, можно, конечно, и об этом порассуждать, только какое отношение это имеет к выбору записей из базы? Делаешь ты поверх всего этого entity или нет - логику выбора записей тебе внутри всё равно реализовывать придётся.
Комбинироваться эти view могут с помощью других view, и таких примеров уже очень много в стандартном приложении. Посмотри, например, на View InventValueTransView, который собирается (через View InventValueTransUnionAll) из нескольких других View, которые в основе своей имеют InventTrans и InventSettlement, отфильтрованные по разным наборам критериев.
Скажу так: за бизнес-сущность вовсе не обязан отвечать класс. Это может быть и View, и Query. Ну или правильнее будет сказать, что класс, отвечающий за бизнес-сущность - это совсем не обязательно класс в смысле объекта AOT типа "класс".
P.S.: Я, наверное, дальше в этой ветке буду только на прикладные вопросы отвечать. Абстрактные идеологические рассуждения, конечно, тоже иногда интересны, но, пожалуй, не сегодня
