Есть таблица с настраиваемыми фильтрами - типа визуальный конструктор запросов. Для обычных пользователей, не программистов. Надо эту визуальщину преобразовывать в запрос к БД, а также сохранять в БД сам запрос и восстанавливать настройки этого запроса в визуальном конструкторе. Т.е. у конструктора есть некий объект, хранящий все фильтры - вот этот объект и надо превращать в SQL и сериализовать в строку для хранения в БД. По идее, можно SQL обратно распарсить в такой объект, но они решили для хранения в БД использовать XML. Поэтому этот объект настроек фильтров должен и в SQL, и в XML (и обратно) конвертироваться.

Штука ещё в том, что UI может поменяться, а сохранённые настройки в БД останутся от старого. Поэтому нужен промежуточный объект, который не будет меняться в зависимости от UI. Что-то типа такого

UI filter settings - DTO object - DB query

Если бы они юзали стандартный EF, то проблемы бы не было - в каждой уважающей себя UI-либе есть его поддержка из коробки, ничего писать не надо - т.е. промежуточный узел с DTO не нужен, все конвертации из UI в запросы проходят автоматически, сами запросы сериализуются в JSON их можно сохранять и снова загружать в UI, восстанавливая все настройки фильтров. Но у них своя ORM на датасетах, при этом хреново сериализуемая (например, у кучи типов нет сеттеров, нужных для сериализации в XML, плюс кода какие-то немереные килотонны - задолбаешься обвешивать атрибутами сериализации и потом полученный гигансткий объект сохранять в БД). Там либо переписывать всё, либо писать DTO. А они ещё усугубляют, заставляя юзать XML, а не JSON (который тоже любой нормальной либой из коробки поддерживается). Я выбрал DTO с минимальными настройками длс запроса - без лишнего мусора их самописной ORM. В результате я должен писать конвертеры ORM - DTO и UI - DTO, а сам DTO делать сериализуемым в XML, чтобы его потом в БД сохранить.