Архитектура для предоставления источника данных для плагинов

Question

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

До сих пор мне не удавалось предоставить общий источник данных с сервера клиенту. То, что я пытаюсь сделать, это передать клиенту «что-то, соединенное с сервером», которое позволяет клиенту сохранять данные (например, результаты поиска или опроса), а затем запрашивать источник данных для данных.

Данные, собранные из различных элементов управления в клиенте, сильно различаются, от вопроса / ответа до поиска / результата - все это я хотел бы направить через мой сервер. Так что каждый клиент не имеет своего собственного подключения к базе данных.

Я думаю о том, чтобы в базе данных моих серверов была таблица с метаданными о данных каждого клиента (типами и столбцами), а затем простая таблица для хранения данных.

Есть идеи по этому или альтернативным подходам?

Answer 1

Сколько данных мы говорим?

Мое первое предложение, которое может не соответствовать вашему API, - это использовать шаблон проектирования команд для отправки и получения данных. Это обеспечивает гибкость добавления или изменения функциональности без необходимости изменения уровня связи, особенно если вы можете загружать новые команды через плагины. Однако вряд ли это будет хорошо работать для плагинов, сделанных клиентом.

Возможно ли для небольших объемов данных позволить клиенту создать файл CSV или XML, сохранить его на сервере и запросить копию при необходимости? Затем вы можете загрузить это в DataTable или аналогичную структуру для выполнения запросов на клиенте. Вы можете сохранить любые изменения, внесенные в данные, и отправить их обратно на сервер, когда клиент покончит с ними. Преимущество этого заключается в том, что клиент может указать данные, которые он хочет, и то, как он хочет их сохранить, а серверные компоненты не заботятся.

Для больших объемов данных ... без понятия. У меня есть опыт создания таблиц метаданных и создания описываемых ими таблиц, а также построения структуры запросов, но я сомневаюсь, что это лучшее решение. Вещи, как правило, быстро запутываются - справочные таблицы, отношения «многие ко многим», каскадные справочные таблицы, иерархии и т. Д. Я бы тщательно подумал о том, какие требования к данным у вас будут, прежде чем идти по этому пути.

Если вы не ограничены в SQL для данных, вы можете рассмотреть возможность использования чего-то вроде RavenDB (или другого решения NoSQL) для хранения их данных. Пока они могут сериализовать объекты для отправки на ваш сервер, вы можете хранить их в базе данных. Отправка запросов на сервер может быть проблемой (хотя я точно не знаю).