Поругайте архитектуру доступа к данным

Вроде вечный вопрос, но что-то я не нашел много ответов на форумах.
Итак, задача - стандартное трехзвенное приложение:
1. БД (или другое хранилище данных, например XML файлы), пусть называется Хранилище данных. БД тоже могут быть разные (SQL, Oracle)
2. WCF-сервис для работы с хранилищем+часть бизнес-логики
3. Web-приложение.

сразу отвечу на вопрос зачем WCF-сервис посередине - кроме Web-приложение будет еще Windows-приложение и может быть Windows-mobile. Кроме того, могут подключаться сторонние web-сайты (но как правило через еще один сервис, потому что c WCF мало кто хочет работать). Но это не главное.
Вопрос в доступе к данным.

Как планируется делать - Хранилище данных всегда возвращает XML. Естественно, схемы определены. Т.е. и SQL Server, и Oracle возвращают XML одной структуры. Все сделано через хранимые процедуры.
Далее DAL библиотека десериализует эти XML-ки в DTO и возвращает на уровень выше (т.е. WCF-сервису). Он в свою очередь "прокидывает" их выше, если надо обрабатывая. Сохранение - обратная операция - DTO->XML->база
Почему выбрана такая схема:
1. Хранилище данных может меняться. SQL Server или Oracle, в будущем вообще не понятно, что еще. Поэтому лучше писать что-то кастомное и на ХП, чтобы не зависеть от структуры БД.
2. Почему XML - чтобы сразу выбрать инфу из нескольких таблиц и не писать много кода для чтения Reader'ом.

Что смущает:
1. Сериализация DTO. Насколько это затормозит все? Реальных данных про это что-то я не нашел
2. Писать вручную много DTO
3. Ну и самое главное - такая схема доступа к данным (через XML) использовалась 6 лет назад (в другом проекте) для работы на Framework'е 1.1, когда не было ни нормального NHibernate, ни EF и т.д. 6 лет - гигантский срок, даже стыдно использовать схемы тех времен :) Но на ум ничего больше не приходит. Прикручивать EF ради прикручивания (если оно реально не поможет) не хочется. NHibernate - не люблю, да и вряд ли он поможет (есть же еще XML-файлы).

Выскажите плз. свое веское "фи".