Передать данные от сервера (asp.net) к оболочке (js/cshtml)
Область веб-разработки для меня новая, поэтому ищу решение...
Обычно если мне нужны какие-то данные - я с помощью ajax обращаюсь к apiController и получаю значение. Сейчас вопрос в том, что к apiController (с помощью url) обратится кто-то другой, и методом POST сообщит мне в название таблицы, в которой произошли изменения и сам вид изменений. А я должна в оболочке отразить эти изменения.
Как из обратиться к серверному методу - я знаю. Мой вопрос, как измененные методом данные донести до оболочки? (или до ViewModel.js)
Как вариант, каким-то образом сразу разбудить оболочку, а оттуда уже запросить информацию у сервера?
Я дополню: сама задача - актуализировать данные на страничке, когда происходят изменения в базе данных. Доступа к базе у меня нет. Ей занимается другой отдел, который и предложил вмонтировать триггеры. Они, в свою очередь, будут вызывать мой урл, таким образом моя программа будет получать информацию, что что-то изменилось.
До этого (мой предшественник) обновлял страничку раз в... секунд, отчего получил мигание эрана клиента и раздражение, что "только выделишь строку, а страничка оп, и обновилась, опять выделять".
Вот неплохой ответ на принципиальный вопрос "как обновить данные в браузере с сервера": https://stackoverflow.com/questions/8110550/is-there-a-rea...
Самое простое - продолжайте обновлять. Только не раз в несколько секунд а раз в пару минут. И не всю страничку а один <div>. ajax-ом получайте новые данные и актуализируйте один блок. Если очень надо (для нетерпеливых) добавьте в этот блок коночку "обновить". Если не хотят ждать - пусть жмут.
А так - хотите WebSockets используйте, хотите пытайтесь HTTP 2.0 заставить работать.
Это и было мое предложение (WebSocket), но "старшим коллегой" оно отмелось.
Прикреплённые файлы
"Только не раз в несколько секунд а раз в пару минут."
Клиент застрелится. Грубая схема происходящего.
Когда клиент заказал пиво - на экране заявка выделена красным цветом. Когда касса одобрила заказ (он попал в базу данных) - она стала черной. Вот это "стала черной" и есть проблема на сегодня.
Клиент застрелится. Грубая схема происходящего.
Ерунда. 15 минут пока пиво ему принесут он ждать может, а 2 минуты пока у него кнопочка не почернеет - нет. А платит он как? Кредиткой оплата тоже не мгновенно присходит.
Сколько одновременно клиентов этим пользоваться будет? 10 - 100 - 1000 - 10.000?
Я ж говорю, очень грубая схема.
Я немного уточню: за один столик можно заказать только один вид пива, а собраться у столика могут и пять, и сто человек. И "заказывающих" аппаратов может быть много, поэтому важно "моментальное" оповещение сайта, если пиво наконец-то доставили, чтоб можно было (разлить его по стаканам) заказать повторно.
Оплаты как таковой нет, просто есть человек, который контролирует заказ. Поэтому я его нарисовала "кассой".
С пивом чисто пример... Сейчас да, жмем на "рефреш", чтобы убедиться, что можем снова заказывать.
И "заказывающих" аппаратов может быть много
Много это сколько? Если не ожидается больше 1000 (ну, до 10.000) единовременно активных клиентов, можно продолжать поллить сервер. Раз в 10 секунд, например. Или вообще - держать долгое соединение, пока сервер не ответит.
Но если и клиентов > 10.000 и скорость отклика важна, то никуда от websockets не денетесь.
Оплаты как таковой нет, просто есть человек, который контролирует заказ. Поэтому я его нарисовала "кассой".
Если в деле человек то экономить секунды на скорости обновления - бессмысленно. Опрашивайте раз в 10 секунд.
Чьё пиво? 😀ihr Bier kommt gleich
На странице можно запрограммировать JavaScript - Promise для XMLHttpRequest (предпочтительный вариант, на мой взгляд, см. link). Т.е. запрос отправляется сразу и соединение остаётся открытым столько, сколько нужно. Я бы ограничил время ожидания максимум 30-60 сек. и отправлял бы новый запрос по истечении этого времени, как предложил мистер выше.он попал в базу данных
Нету, нету у меня хттпреквестов. У меня вообще нет контакта с бд, я пишу данные в SharedTypes и вызываю соответствующий метод ("заказать пиво"). Что происходит дальше - для всех закрытая информация. Ибо работой с бд занимается другой отдел фирмы, триста км от нас, связь через емайл.
Схема такая:
Оболочка (cshtml)
ViewModel (js, через ajax вызывает apicontroller)
ApiController вызывает серверную функцию
Серверная функция вызывает эти хитрые методы и возвращает результат
Учитывая, что нет доступа к БД, тут все немного сложнее: сначала нужно сообщить твоему webapi о том, что произошли изменения в БД, а потом сообщить клиенту об изменениях.
Наверное, самый простой способ сообщить webApi, о том, что произошли изменения в БД, если это ms sql, это написать триггер с EXTERNAL NAME.., который является CLR-триггером и который будет делать вызов твоего WebApi по http. Но это дурно пахнет, такие вещи делаются при помощи очередей (service bus) и обработчиков очередей - этим занимаются architect-ы и опытные dev-ы.
Для того чтобы сообщить клиенту о пришедших изменениях из пред-го шага все-равно придется "держать" соединение между клиентом и сервером(webapi), а это или websocket-ы или нечто другое, посмотри на SignalR.
А чем, кстати, старшему коллеге web-socket-ы не понравились? Если ему они не нравятся, то предложи ему предложить альтернативное решение.
Что то мне кажется что ты пытаешся найти кконкретное решение конкретной проблемы не имея концепта обновления данных.
Попробуй начать именно с этого - с концепта.
Есть база, есть клиенты - как клиенту узнать об обновлениях в базе? Клиент может спрашивать базу, база может оповещать клиента. Клиент - не обязательно твоя страница. Это может быть и твой сервер. Может быть и двухступенчатая схема с различными подходами.
Когда то в одном из проектов была схема подписки и сообщений. Клиент подписывался на определённые изменения, а сервер его о них уже оповещал.
Это мало чем поможет сгенерированному сервером view (cshtml). "Проблема" в обновлении view, вызов метода класса, обращающегося к бд идёт через контроллер (или сам контроллер обращается к бд, но это уже не MVC). Вот этот метод DataTriggerController должен запрашивать JavaScript по AJAX.Когда то в одном из проектов была схема подписки и сообщений. Клиент подписывался на определённые изменения, а сервер его о них уже оповещал.
вызов метода класса, обращающегося к бд идёт через контроллер
опять конкретика. Нет сейчас ни классов ни БД 
Если хотим идти от страницы, то нужно вначале определится какой использовать принцип обновления части страницы. А от этого уже плясать дальше- нужно запрашивать обновления или получать. При этом, от кого именно или кого - не важно пока.
" А что это за POST Request в коде на картинке? 😁""Не подскажете, что такое ajax? 😁"
не скажуууууу! :D :D :D
Я просто действительно помню "сишарповское" OpenConnection и здесь для меня не очевидно, где она открылась, где закрылась.
"Что то мне кажется что ты пытаешся найти кконкретное решение конкретной проблемы не имея концепта обновления данных."
Оно! Прямое попадание.
Посекундное обновление я не пробовала, ибо мне сообщили, что экран так мигает, и я сразу решила, что надо зайти с обратной стороны. Мол, пусть информация об изменениях приходит со стороны.
Я даже отловила ее уже (мое первое сообщение - картнка), на сервер передать могу, а вернуть с сервера - мозгов не хватает. Ведь до этого я все данные получала по запросу из оболочки...
Но в мне действительно надо подумать в целом, как я хочу обновлять информацию. Ибо у нас много разного накручено, в том числе и переписка - надо вовремя уведомлять, когда приходит ответ.
"сначала нужно сообщить твоему webapi о том, что произошли изменения в БД, а потом сообщить клиенту об изменениях."
Да!!!! Именно так я и нарисовала сверху.
"сообщить webApi, о том, что произошли изменения в БД, если это ms sql, это написать триггер с EXTERNAL NAME.., который является CLR-триггером и который будет делать вызов твоего WebApi по http. Но это дурно пахнет, такие вещи делаются при помощи очередей (service bus) и обработчиков очередей - этим занимаются architect-ы и опытные dev-ы."
Это как раз не мои проблемы, ибо БД я не касаюсь. А отдел, который ими занимается, к счастью, имеет спецов нужного уровня :)
"А чем, кстати, старшему коллеге web-socket-ы не понравились? Если ему они не нравятся, то предложи ему предложить альтернативное решение."
Его альтернативное решение выглядит так:
[WebInvoke(Method = "POST", UriTemplate = "datachangedtrigger/{tablename}/{primaryKey}?apiKey={apiKey}&changeType={changeType}", BodyStyle = WebMessageBodyStyle.Bare)]
[OperationContract]
void DataChangedTrigger(string apiKey,string tablename, long primaryKey, int changeType);
Погуглив, я поняла, что мне нет смысла адаптировать это решение под уже имеющуюся разработку...
Но если и клиентов > 10.000
К счастью, нет. По моим рассчетам максимальное число одновременных пользователей врядли когда дойдет до тысячи. Реальных пользователей первое время будет человек 80, не больше.
Если в деле человек то экономить секунды на скорости обновления - бессмысленно. Опрашивайте раз в 10 секунд.
Ну вот мы и вернулись к высказыванию АлексНека, что сперва надо решить, чего я хочу, а уж потом думать над реализацией :)
Не знаю, что такое WebInvoke, но это и не важно, важна суть. Смотри, с БД приходит сообщение данные изменены на твой WebApi(напр. POST), теперь твой front-end(клиент) как-то должен об этом узнать. Http-сервер может отправить данные клиенту, только если существует tcp-ip соединение между ними, а это опять же или WebSocket-ы или что-то другое, что держит persistent connection между клиентом и сервером. Или клиент с какой-то периодичность опрашивает сервер, но тогда тебе промежуточно нужно как-то хранить инфо о БД-измененеиях.
У вас серверный ms-стек - asp.net, посмотри на библиотеку SignalR и ее push-уведомления. SignalR абстрагирует тебя от транспорта (WebSocket-ов и пр.) и позволяет сконцентрироваться на бизнес-логике: тебе придет уведомление с БД и ты сразу отправишь его клиенту - сделаешь push.
Прокомментирую еще пару постов:
"Посекундное обновление я не пробовала, ибо мне сообщили, что экран так мигает, и я сразу решила, что надо зайти с обратной стороны. Мол, пусть информация об изменениях приходит со стороны."
- Может кто-то с кривыми руками front-end делал, что экран мигает. Я не очень силен во front-end, но почти уверен, что относительно легко можно избавиться от мигания экрана.
"Я даже отловила ее уже (мое первое сообщение - картнка), на сервер передать могу, а вернуть с сервера - мозгов не хватает. Ведь до этого я все данные получала по запросу из оболочки"
- Вообще-то уведомлять клиентов с http-сревера - не совсем "стандартная" работа http-сервера. Стандартное взаимодействие клиента и сервера в http-протоколе: client отправляет http-запрос и получает http-ответ.
Может кто-то с кривыми руками front-end делал, что экран мигает.
А я вообще оболочки в своей жизни лишь чуть-чуть на wpf лепила. HTML/JavaScript, как и Bootstrap/Knockout - для меня пугающие слова. Но деваться некуда, в проекте, да и в отделе - одна, кто занимается "веб-разработкой". Обнять и плакать. Но я все же искренне надеюсь, что начальство знало, на что шло, беря меня на работу :)
В понедельник обязательно посмотрю SignalR, я наконец-то научилась не тащить работу домой))))
SignalR - опирается в конце концов на сокеты, но шеф это может и не найти
Я вебом давно уже не занимался, а когда было то пользовали готовые либы с "AJAX обновлением".
Но вариантов не так уж и много похоже
SignalR
https://www.codeproject.com/Articles/889240/Real-Time-Data...
https://www.bitovi.com/blog/how-to-add-real-time-data-to-y...
https://techbrij.com/database-change-notifications-asp-net...
Pusher
https://blog.pusher.com/the-easiest-way-to-add-real-time-f...
https://pusher.com/tutorials/counter-aspnet/
AJAX
https://docs.microsoft.com/en-us/aspnet/ajax/
http://support.nevron.com/KB/a175/implement-real-time-char...
Посекундное обновление я не пробовала, ибо мне сообщили, что экран так мигает
Экран будет мигать, если обновлять всю страницу
Типа вот так
window.location.reload()
Как уже сказали, надо по таймеру асинхронно запрашивать данные из контроллера и, если они изменились, обновлять твой статус заказа пива на страничке.
Правильный выбор технологии для подобного требования - это Server-Sent Events, и SignalR это как раз и есть имплементация SSE в ASP.NET.
