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

EP>В итоге у тебя будет и EDSL для передачи фильтров, и EDSL для передачи списка полей, плюс приложение будет знать о конкретных полях. Так в чём в итоге профит, если вся абстракция уже протекла?

Nope.

EP>Дело не compile/run-time, а в отсутствии типизации.

Которая тут не нужна.

EP>Например проверять версию схемы в runtime.
EP>С DAL у тебя точно такие же проблемы. Точнее даже хуже — например обновил схему, типа обновил код, но ошибки типа неверных имён полей в тексте запросов и т.п. могут спокойно дожить до runtime'а.

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

Далее, нам нужно завести новое поле — добавляем новую запись в таблицу метаданных, запускаем скрипт — скрипт делает миграцию (делает ALTER TABLE нужной таблице).

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