Есть большая система, построена на EAV (обычных реляционных таблиц мало, в основном системные), полностью DB-aware, ВСЯ логика в хранимках. Всем этим питается простенький скриптовый движок - делает sql-запросы, отрисовывает html-странички, отдает web-серверу.
Появилась необходимость реализовать небольшое (пока) desktop standalone приложение(.Net/Mono) (в будущем может быть даже мобильное), которое работало бы оффлайн, с собственным локальным хранилищем (sqlite), и синхронизировалось с основной базой.
На сервере скорее всего будет веб-сервис, посредством которого клиент будет общаться с основной системой (на время подключений).

С клиентом есть 3 варианта:
1. Реализуем в локальном хранилище клиента похожую EAV-модель как и в основной базе. На нее перетягиваем нужные для работы классы. Получаем простую и гибкую синхронизацию между приложениями, не изменный универсальный веб-сервис (даже если будут появляться новые классы - ему все равно), но проблемы при построении запросов на клиенте, ORM-ку к такой модели уже не подвяжешь и т.д.
2. Рисуем на каждый EAV-класс настоящий .Net-вский класс, как на сервере, так и на клиенте. На сервере маппим нужные нам EAV-классы на .Net-классы, а дальше гоняем их по сервису (например wcf), работаем с ними на клиенте, сохраняем в локльном хранилище (юзаем любой ORM) и т.д. Минус в том, что при добавлении новых классов в EAV нужно будет пересобирать как клиента, так и сервис.
3. Берем лучшее от 1-го и 2-го. На web-сервере маппим EAV-классы на .Net-классы похожей структуры (ObjType, ObjParameter, Obj и т.д.). Т.е. из объектов любых классов всегда получаем один и тот же набор, т.е. веб-сервис остается не изменным. Дальше транспортируем эти унифицированные классы по простенькому веб-сервису на клиента. А вот на клиенте у нас уже есть нужная нам объектная модель (полный ООП), но каждый класс и член такого класса (с помощью атрибутов) мы заранее привязываем к айдишнику нужного класса и параметра в EAV, т.о. с помощью Reflection сможем отмапить унифицированные плоские классы, пришедшие с сервера, на нашу ООП-модель. Ну а там все прелести ORM, как во 2-м варианте. Так же и в обратную сторону - маппим классы в структуру, гоним по сервису, вставляем в EAV. Т.о. при добавлении/модификации классов в EAV, не нужно трогать серверную часть, изменяем только клиента.

Посоветуйте, что выбрать?

Склоняюсь к 3-му варианту, но думаю - не получу ли неприятностей из-за универсальности.


ПС задавал такой же вопрос в РИС - http://www.sql.ru/forum/1092975/vybor-arhitektury-klientskogo-prilozheniya-dlya-eav-bazy
Интересно услышать мнение относительно конкретной платформы.

Cat2Максим Н,

Для начала бы хотелось узнать, чем вызван выбор EAV?

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