#c# #architecture
#c# #архитектура
Вопрос:
у меня есть клиент-серверное приложение, показывающее, где клиенты предназначены для сенсорных экранов. Цель состоит в том, чтобы собирать данные из опросов, вопросников и выполнять интерактивные задачи с клиентом (например, поиск в базе данных). Клиент — это приложение WPF, в котором я с сервера могу выводить пользовательские элементы управления и отображать их. Пока все хорошо.
До сих пор мне не удавалось предоставить общий источник данных с сервера клиенту. Чего я пытаюсь достичь, так это передать клиенту «что-то, подключенное к серверу», что позволяет клиенту сохранять данные (например, результаты поиска или опроса), а затем запрашивать данные у источника данных.
Данные, собираемые с различных элементов управления в клиенте, сильно различаются, от вопроса / ответа до поиска / результата — все это я хотел бы направить через мой сервер. Чтобы каждый клиент не поддерживал собственное подключение к базе данных.
Я думаю о чем-то вроде наличия таблицы в базе данных моих серверов с метаданными по данным каждого клиента (типам и столбцам), а затем простой таблицы для хранения данных.
Есть идеи по этому или альтернативным подходам?
Комментарии:
1. нельзя ли удовлетворить это требование, предоставив вашим элементам управления доступ к данным через WCF?
2. Да, это возможно. Но я предоставляю API, позволяющий другим разрабатывать плагины, и эти плагины также должны иметь доступ к источнику данных. И я не знаю структуру их данных. Возможно, можно было бы предоставить словарь <string, строка>, один для чтения и один для записи?
Ответ №1:
О каком объеме данных мы говорим?
Мое первое предложение, но это может не соответствовать вашему API, заключается в использовании шаблона проектирования команд для отправки и получения данных. Это обеспечивает гибкость добавления или изменения функциональности без необходимости изменять ваш уровень связи, особенно если вы можете загружать новые команды через плагины. Однако маловероятно, что это будет хорошо работать для плагинов, созданных клиентом.
Для меньших объемов данных было бы целесообразно позволить клиенту создать файл CSV или XML, сохранить его на сервере и запросить его копию, когда это необходимо? Затем вы могли бы загрузить это в DataTable или подобную структуру для выполнения запросов к ней на клиенте. Вы могли бы сохранить любые изменения, которые были внесены в данные, и отправить их обратно на сервер, когда клиент закончит с этим. Преимущество этого заключается в том, что клиент может указать, какие данные они хотят и как они хотят их хранить, а серверным компонентам все равно.
Для больших объемов data…no идея. У меня есть опыт создания таблиц метаданных и таблиц, которые они описывают, а также построения фреймворка запросов поверх этого, но я сомневаюсь, что это лучшее решение. Вещи, как правило, быстро запутываются — справочные таблицы, отношения «многие ко многим», каскадные справочные таблицы, иерархии и т.д. Я бы тщательно подумал о том, какие требования к данным у вас будут, прежде чем вы пойдете по этому пути.
Если вы не ограничены SQL для данных, вы могли бы рассмотреть возможность использования чего-то вроде RavenDB (или другого решения NoSQL) для хранения их данных. Пока они могут сериализовать объекты для отправки на ваш сервер, вы можете хранить их в базе данных. Отправка запросов на сервер может быть проблемой (хотя я не знаю наверняка).