How could I implement a Comet architecture in a ASP.Net MVC?
The paid alternative
There are great comments about the question in this thread.
And based in the fact you can use handlers in a MVC app:
WebSync
will do the work : )
As long as you need to implement server push support onto your ASP.NET MVC application you will need some extra functionalities like detection of client status etc. I suggest you to try PokeIn comet ajax library which you can find sample project here
I doubt you will find something out of the box for MVC but you can always implement the client side code that handles timeouts and reconnects to an AJAX-enabled WCF service that polls for whatever event you want to be notified for. Be sure to set the timeout of the service to a higher value.
Edit 24.11.2013
Since the original question was posted SignalR was released which is a library to do just that.
Related
I normally develop with ASP.NET MVC, but I'm very new to Blazor. I'm creating a new site in Blazor WebAssembly. The very first thing I need to do is create a page with a simple form, that can create or update an item and send it to the server, to be saved in the DB. I can either send the object using SignalR, or use HttpClient to post it to a controller action. What's the best practice here in Blazor Wasm? I was tempted at first to just use SignalR all the time.
I've seen examples of using both, but very little to help decide which to use in what circumstances. This was about the most useful thing I could find but it doesn't answer the exact question and it's also not specific to Blazor.
The question is specifically about the simple create update operation, but other pros and cons of both would be very helpful. Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Thanks a lot
Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Yes, I think it is. CRUDL operations are transactional and asynchronous. Do a transaction, wait forever on the user, do another transaction,.... I would always do these through an API Get/Post.
The only time I would consider SignalR is where I'm passing object defined objects - such as a Dictionary<string, object>. They are a pain in controller API calls.
How can I implement the reverse ajax like comet or Websync in asp.net simple web pages?
I want to get push the updates on server then reverse the response on all clients with in a second.
Because I'm new and don't have any idea about the reverse ajax ?
Have a look at WebSync. It uses the Bayeux protocol (so you can integrate with solutions from other vendors), uses WebSockets when available, supports web browsers back to IE 5.5, and has client SDKs for just about every software platform.
Have your clients subscribe to a channel (e.g. '/data'):
var client = new fm.websync.client('websyncurl');
client.connect();
client.subscribe({ channel: '/data', onReceive: function(e) {
alert(e.getData());
});
Then when you want to send something from the server:
WebSyncServer.Publish("/data", Json.Serialize(data));
Disclaimer: I work for Frozen Mountain.
Use SignalR http://signalr.net/ it enables to push content to client
SignalR works well with MVC, and the Chat Application they use in the sample is MVC. As pointed out by #Garath, there's a tutorial to follow on ASP.NET. Another technology to consider is Knockout, they work well together with the instant updates to the UI. I have just finished a messageboard type application using Knockout, MVC and SignalR and it works really well.
http://knockoutjs.com/
There's a TODO application here which implements the mentioned technologies also, http://www.codeproject.com/Articles/322154/ASP-NET-MVC-SIngalR-and-Knockout-based-Real-time-U
I'm implementing a Core Service "Facade" for some lazy programmers that don't want to change their coding style (me included), and wanted to implement object cache, which obviously leads to the grand question of "how long and how much should I cache".
The ideal answer is to cache forever except when data is changed.
Is there a way (via some WCF event perhaps) to implement a "listener" for data changes that could be used to remove items from their cache?
BTW, I am using .NET's native ObjectCache (MemoryCache) with a 1 minute sliding cache policy for now.
Thanks,
N
There is no such system built-into either WCF or Tridion that I know of.
You could of course roll your own, where you:
Listen for changes to the relevant data on the TCM server with Event Handlers
Have those event handlers forward the event to a central notification server
Have your WCF clients register with that notification server when they start up
Have notification server subsequently send the notifications on to the connected clients
This is essentially quite similar to how Tridion's Broker Object Cache works on the Content Delivery tier.
If you're interested in implementing such an approach, I'd suggest having a look at the Signalr project, which takes a lot of the hassle out of it.
Edit: it turns out WCF has something akin to what you're asking for called Callbacks. See this question and this blog post.
I am trying to develop a comet page using Asp.net. Surfed a lot and found some plugins like Pokein. I feel this blog, to be best suited for my project as it goes in hand with jQuery. But this is in MVC. I wonder if i can do the same with ASP.NET website pages. All i need to do is to free up the worker process during the long waiting ajax-call duration. In MVC, async controllers come handy. Could someone help me if I can do the same with website pages(say: free up the worker process during the long waiting jquery Ajax call inside the static web method). I read about async pages in websites here, but this will take a full posback and the page is blocked during the long wait. (basically free up worker process during pre-render and wait for long polling, but the UI still keeps refreshing as the page life cycle is not completed)
Thanks in advance for your advice geeks...
'Push' style architectures on the web using purely ASP.NET, JavaScript, JQuery, AJAX etc. can be difficult and involved to implement. Normally the route most go is more of a glorified 'pull' model where a timer somewhere client side will check back to the server for the needed data or state required and then preform the necessary action. If you truly want a more of a push architecture with purely web technologies, you will want to look into the long polling 'Comet' architecture. You can read more about it below:
Comet (programming):
http://en.wikipedia.org/wiki/Comet_(programming))
Ideally in the Microsoft world if possible you could jump over to a rich client technology like Silverlight to work with a duplex polling WCF service in which a client subscribed to the server can get updates pushed from the server back to the client. Anytime (as of today)I would need to implement any type of 'push' architecture today I would personally opt for Silverlight as there are numerous examples on how to implement this easily. If you are interested take a look to the (2) links below:
Pushing Data to a Silverlight Client with a WCF Duplex Service:
http://weblogs.asp.net/dwahlin/archive/2008/06/16/pushing-data-to-a-silverlight-client-with-wcf-duplex-service-part-i.aspx
How to: Build a Duplex Service for a Silverlight Client:
http://msdn.microsoft.com/en-us/library/cc645027(VS.95).aspx
Regardless, COMET/Silverlight/Flash, etc. are probably not going to be a widely used option going forward anyways with web sockets in HTML5. But since the spec is not quite ready (see: http://ishtml5readyyet.com/) you might needs to look at using a Silverlight control on your ASP.NET page in the meantime and it will work well.
I've been a longtime ASP.NET developer in the web forms model, and am using a new project as an opportunity to get my feet wet with ASP.NET MVC.
The application will need an API so that a group of other apps can communicate with it. I've always built API's out just using a standard web service prior to this.
As a sidenote, I'm a little hesitant to plunge headfirst into the REST style of creating API's, for this particular instance at least. This application will likely need a concept of API versioning, and I think that the REST approach, where the API is essentially scattered across all the controllers of the site, is a little cumbersome in that regard. (But I'm not completely opposed to it if there is a good answer to the potential versioning potential requirement.)
So, what say ye, Stack Overflow denizens?
I'd agree with Kilhoffer. Try using a "Facade" wrapper class that inherits from an "IFacade". In your Facade class put your code to consume your web service. In this way your controllers will simply make calls to the Facade. The plus side of this being that you can swap a "DummyFacade" that implements the same IFacade interface in that doesn't actually talk to the web service and just returns static content. Lets you actually do some unit testing without hitting the service. Basically the same idea as the Repository pattern.
I would still recommend a service layer that can serve client side consumers or server side consumers. Possibly even returning data in a variety of formats, depending on the consuming caller.