Цитата:
Сообщение от
belugin
1. Не поедет - это такой же код как и другой
Не совсем. Уровней вложености много.
Цитата:
Сообщение от
belugin
2. Query плохо читаемо: для того, чтобы узнать, какие есть условия на поля надо активно возить мышкой и нажимать на плюсики. Даже для того, что убедится, что оно не отсортировано. Т.е. визуализация Query содержит много лишних деталей, но при жтом нужные детали запрятаны глубоко.
В том то и дело.
В АОТ структура запроса отделена от кода. Следовательно:
1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)
2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.
Но что-то я ушел от темы.
В общем, я согласен, что паттерн ExpressionBuilder позволяет сделать интересный код.
Но у него все ж таки есть недостатки, связанные с глубиной.
1. как я уже говорил могут поехать перекрестные ссылки
2. по-моему, нельзя будет поставить точку останова на конкретный метод (дебаггер остановится на первом вызове, а затем в дебаггере нужно будет заходить в каждый парм-метод)
3. возникают очень тонкие и неявные побочные явления, связанные с порядком вызова методов и их аргументов
4. не дай бог какому-нибудь из методов вернуть значение Null.
5. непонятно как возвращать параметры
В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.
В общем, как руководитель проекта я не стал бы запрещать подобную запись, но и рекомендовать к использованию тоже бы не стал.