Так что обычно посредник создает веб-страницу для зрителя / браузера
Я бы с этим немного не согласился.Я бы сказал, что посредник будет генерировать данные, которые затем могут быть использованы представлением.Представление может представлять собой ASP.NET WebForm, представление бритвы ASP.NET MVC или WinForm в настольном приложении C #.
Если вы хотите истинное разделение данных и представления, вам, вероятно, следует подумать о созданиисерверная часть вашей системы - веб-сервис, который может использоваться веб-сайтом / веб-приложением или настольным клиентом / двоичным файлом, например
БД SQL + файловая система -> бизнес-логика / промежуточный уровень -> просмотр (веб)/ Desktop / Mobile)
Ваша первая реализация представления будет бинарным представлением Desktop C #.
И что более важно, как мне передавать обновления / уведомления от БД до середины изатем к приложению c # ???
Исходя из этого, я предполагаю, что вы хотите, чтобы приложение C # мгновенно получало обновления, и хотя ваше приложение не является веб-приложением (HTML / JSи т.д.) на самом деле это веб-клиент.
Подобные уведомления обычно достигаются несколькими способами.
- HTTP-опрос
- HTTP-длинный опрос
- HTTP Streaming
- WebSockets
Последний теперь является стандартом для двусторонней полнодуплексной связи в реальном времени между клиентом и сервером.Однако, если частота обновлений очень низкая, вы можете просто внедрить веб-сервис, который ваш клиент C # может опрашивать через большие промежутки времени, чтобы проверить наличие обновлений.
Если частота обновлений является разумнойи ваше требование для Push-уведомлений предполагает, что это так, тогда я бы предложил систему push-уведомлений в реальном времени, и поэтому я бы предложил использовать сервер и клиент WebSocket.Существует несколько примеров серверов и клиентов WebSocket, таких как:
Если вы предпочитаете избавиться от необходимости внедрять и размещать собственную инфраструктуру обмена сообщениями в реальном времени, вы можете рассмотреть размещенный сервис реального времени .