Есть большая система, построена на 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-му варианту, но думаю - не получу ли неприятностей из-за универсальности.

Petro123если мы про Веб-проекты, то нужно убрать слово EAV из всех абзацев.
Какая разница, как там в БД устроено и какое у неё название?
Дык в этом и соль, в транспорте, и организации клиента.
Т.к. база не нерялиционная, появилась идея максимально унифицировать транспортную часть.
А вот нужно ли это делать или нет, вопрос...

Petro123Максим НТ.к. база не нерялиционная, появилась идея максимально унифицировать транспортную часть.
переведи)))
По классике = это ОРМ. А ему EAV не нужен.
______________________________________________
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
AutoPOI.ru — ГИС-технологии для Oracle


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

mad_nazgulМаксим НПосоветуйте, что выбрать?

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

На сколько я понял вся бизнес-логика находиться в ХП.
И скорее всего в них же есть все что вам нужно.

Соответственно вам нужно работать ч/з них.

Т.е. вам нужен "интерфейс" который позволит вашему приложению обращаться к ХП на сервере.

А напрямую читать/писать в структуру типа EAV лучше не надо.
Проблем будет много.
А уж использовать ORM вообще смерти подобно.

Да, на основной базе используются ХП (где есть логика особенная), а в основном просто происходит вставка через стандартные EAV-процедуры (добавить объект, удалить объект и т.д.).
В любом случае логика (пусть и не большая) будет дублироваться, т.к. на клиенте я ни как не смогу воспользоваться ХП основной базы.
При синхронизации возможно придется вставлять и посредством процедур. Тут снова есть надежды на Reflection - доработать кастомные атрибуты классов так, чтобы можно было в классе указать, что вот данный класс нужно вставлять не стандартной процедурой вставки EAV, а какой-нибудь кастомной процедуркой. Опять же в транспорте ничего не меняется, можно привязывать любые классы к вызову любых процедур.

Petro123Максим Н,
Цель - 50% оффЛайн приложение клиент-сервер.
Так?
Сделать не так просто, т.к. сложно выделить куски Модели для перекачки на клиента в офф-лайне.
1. Неужели проблемы со связью?
2. В net AFAIK есть ДатаСеты которые OffLine

100% оффлайн, в плоть до того, что сети может вообще не быть у клиента - выгружает файл, засылает по почте (передает на флешке), загружает в базу.

Petro123Максим Н,
зайдите на форум ЯП - там всё это уже есть.
EAV это для мазохистов.
Ок, пойду к дотнетчикам.

Petro123EAV это для мазохистов.
Возможно, но выбирать не приходится.

Petro123Максим НВозможно, но выбирать не приходится.
тогда максимально закройтесь от "данного слоя" напр. паттерн Фасад и т.д.
Чтобы в любой момент - выкинуть на помойку.

Попробую, спасибо.

mad_nazgulМожете пояснить что значит "стандартные EAV-процедуры (добавить объект, удалить объект и т.д.)"
Т.к. в моем представлении EAV это один из способов представления сущностей на БД

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

mad_nazgulПочему?!
Если есть доступ к БД, то и есть доступ к ее ХП.

Доступа к этой БД на клиенте нет. Клиент полностью автономный. Общается с БД посредством файлов. У него свое локальное хранилище (sqlite). Соответственно всю логику придется повторять (и заодно изменять под цели автономного приложения).

mad_nazgulТ.к. я не сторонник ORM и в частности Entity Framework (а уж для EAV точно не подойдет)
Почему бы просто не работать с БД напрямую ч/з ADO?
[/quot]
Можно и напрямую, но нужно будет каким-нибудь образом конвертировать EAV из основной базы в реляционку на клиенте.
Как это лучше сделать: статически (завязаться жестко на каждый класс EAV), либо динамически, пока не решил.

mad_nazgulЕще лучше!
Пишите свое клиентское приложение как вам удобно.
С удобными для вас объектами, сущностями и пр.
Делаете выгрузку, например в XML.
Пишите свой ETL (или находите сторонний), который бы грузил ваши XML в БД.
Думаю для этого уже есть соотв. ХП.

Как раз смотрю в эту сторону.
Единственное, думал не "грузить XML в БД", а грузить xml сразу в объекты класса клиента, а уже классы сохранять в БД (причем совершенно неинтересно какая именно БД на клиенте будет использоваться, ее можно менять). Т.е. плясать именно от классов клиента, а не от таблиц.

mad_nazgulНе надо ничего конвертировать используйте ХП ;-)

ХП само собой, но в большинстве случаев они стандартные, не несут никакой логики, просто распихивают значения параметров по EAV-таблицам и все. А запрос на выборку объектов любого класса такого EAV вообще всегда будет одинаковый, только айдишники разые и количество параметров. Вот я и думаю, что я просто сериализую эти классы в XML/JSON/BIN/ETC и сохраню в файл. А на клиенте просту такой файл и распихаю по объектам своих настоящих классов. Так же наоборот.
Для того, чтобы при появлении нового класса в EAV мне не повторять одну и ту же процедуру: написать запрос для его получения, сделать метод WEB-сервиса для его выгрузки, объяснить клиенту как его принимать и т.д.

Злой БобрМаксим Н,

Поднимите локальный веб-сервер и пусть люди работают с ним как с обычным. Вам останется лишь сделать синхронизацию на уровне БД, что намного проще переписывания клиента. Ну типа вот так вот ...

Dimitry SibiryakovМаксим НЕсть EAV в большой БД (Oracle), она все обложена стандартными хранимками, которые могут создать класс, добавить к нему объект, удалить объект, изменить и т.д.

Клиент полностью автономный. Общается с БД посредством файлов. У него свое локальное хранилище (sqlite). Соответственно всю логику придется повторять (и заодно изменять под цели автономного приложения).
Т.е. сначала заботливо разложили грабли использовав для локального клиента sqlite вместо того же Oracle XE, а теперь пожинаете плоды этого неудачного решения и плачетесь в жилетку?.. Ню-ню...

И локальный web-сервис и Oracle XE можно было бы заюзать, но минус в том, что данный клиент создается с закосом на использование (в будущем) на мобильных девайсах (e.g. Mono). А развернуть на них данное ПО проблематично.

kmawя бы делал так:
1) клиент - полностью независимый от основной "большой полностью на EAV" системы - пофиг как, в зависимости от того, что хочется /требуется.
2) отдельный модуль для синхронизации данных на основе веб-сервиса

Я тоже остановился на этом варианте.

Теперь возник вопрос как должен выглядеть модуль синхронизации и веб-сервис.
Должен ли веб-сервис знать о классах, используемых на клиенте, либо он просто выгружает нужные EAV-объекты в универсальный XML скопом. А уже модуль синхронизации парсит xml и распихивает его либо по конкретным реляционным таблицам клиента, либо по объектам классов (уже настоящих .Net-овских классов), затем сохраняя их в БД.
Т.о. если появился новый класс в EAV, то в транспорте и на web-сервисе в коде ничего не меняется, только в клиенте.