Sending data to a view from a controller event (without client request) ASP.NET MVC 4

Question

this question seems to be noob but i've been searching in Google, also in this forum and I couldn't find exactly what i'm looking for.

I have a SonimMQ object in the Controller in listening mode, so when I receive one or many messages, I parse them and want to send them to my View (could be a Grid or a Chart for a real time update). Is there a way to send data from a Controller Event (in this case is the _OnReceiveData SonicMQ Event ) to a View without the client request?

I know I could implement a Timer with jQuery ( setTimeout ) for pulling data from the Controller but I just want to know if there's another way to implement this.

I've also read about jQuery .Controller but it seems it works only with mouse and keyboard events, not with " Controller events ".

The closest answer i've found here is this one but it uses jQuery setTimeout.

Perhaps it's a paradigm problem because i'm a desktop application developer and i'm trying to solve this as in desktop app model. I'm just beginning with web development. So, please excuse me if this question is so obvious.

I appreciate any help. Thanks!

Answer 1

I think that you are after web sockets. Please look at this link So... ASP.NET MVC and WebSockets?

SignalR looks like the best bet at the moment.

Answer 2

I'm going to say the short answer is no, but I need some more context around the question.

Can you share some code?

I am guessing that SonimMQ is long running service, in this case a message Queue.

A controller does not a live longer than the request (usually a couple seconds at a time). An each request is isolated from another (for the most part, there are methods to share data across requests)

If you looking for a long running process, you can use a service, a windows service for example. It's a bit hacky, but you can use the HttpCache API and set a timeout.

The hardest concept for a desktop dev transitioning to the web is the statelessness of the web. In the desktop world, you can store state and trigger action based on events. In the web world this is not so much the case. In a lot of ways it's the beauty of the web, but it's also the curse of the web, because ultimately we want the desktop experience on the web.