I'm about to create a small web app on Asp.Net 3.5.
Thought this time maybe I should try using Backbone.js..
Is it practical/easy to implement?
I've just spent the whole day trying to set up a WCF Service to return Json without positive results.
I would love to hear the best path for implementation from someone who has already used Backbone.js with Asp.Net.
Alternatively I would love to hear of alternatives that are easy to integrate with Asp.Net.
I've just spent the whole day trying to set up a WCF Service to return
Json without positive results.
Take a look at this tutorial, is short and straight to the point.
Thought this time maybe I should try using Backbone.js.. Is it
practical/easy to implement?
Well... as usual, it basically depend on what you want to do. Backbone can help you if you want to implement the MVC pattern in your client-side code, but it requires some time to get into the APIs so if your goal for the moment is just to create and consume a WCF service using Javascript you could consider using jQuery or MooTools and then switch to Backbone if you need.
PS
Here and here you'll find two quickstart backbone tutorials.
Use the REST Singleton Service template in the WCF REST Starter Kit Project Templates to get WCF with JSON support up and running quickly.
Related
Lets say I have a standalone ASP.NET Core Web API as its own project (since I don't want to merge it w/ my MVC app)
I now want to create an MVC web application (another project, but same solution) that will make calls to the API. I am aware that for ajax requests I will directly call the API through JavaScript which is straight forward.
However, I am a bit confused as to how the MVC controller would make calls to the same API to populate the ViewModel and send to the View when a user requests a page i.e. http://myurl/books/1
I am aware that if I was using something like Angular which is fully client-side I wouldn't be running into this issue.
That's a good question. There's three different approaches that I can think of:
The first is to call the same API from your MVC controller with a HTTPClient object. Might seem a bit weird calling "yourself" on the server side but it works. In my opinion this isn't a great solution, because you're losing type-checking and you'll also making an unnecessary call over the network, and you also have to parse and convert the response back from WebAPI to your .net objects.
The second approach is to move all of the logic that's inside the API into a new project and compile it all down to a DLL. Your Web Api can then call the code inside the library and your MVC project can do it too. A pretty good approach.
The third approach is to do what you've suggested - don't populate the Model at all on the server side inside your MVC project and just do it all from the client side. Yes, this will work great with Angular but you can also do this yourself using bog-standard JQuery or Knockout. This approach means much more client side javascript to write (use Typescript!) but you'll end up with a much nicer separation of concerns and cleaner solution.
I'd like to access some web api's using .net code, but am not sure if there's a way to generate a client side wrapper of some kind for these? Perhaps a code generator that can look at the web api documentation or through sample calls and generated .net classes and methods to encapsulate the api?
There isn't. REST-based APIs do not have a WSDL or service contract that could be used to generate a client stub.
That said, consider the following alternatives:
REST Coder: this is interesting research but no definitive tools yet.
Google for .NET WCF REST client: it turns up a lot of interesting results.
As far as I know, there isn't.
However, you can try one of the many wrappers available, that makes your life easier once you have to write less code.
Check this one out I've written a few months ago:
http://webapiclient.azurewebsites.net
I have been reading up on WCF and was looking for a good tutorial on creating a WCF Restful service that returns Json. I cant seem to find any that are really worth reading, does any have any ones they would recommend for someone who just wants to start with the basics and learn about WCF Restful service? I am unsure if I should start with WCF 3.5 or WCF 4 too. I am using Visual Studio 2010, so I could potentially do either one or both.
WCF4 already has nice built-in templates for JSON, whereas in WCF 3.5 it's a bit fiddly and you need to manually add support for that.
check this out for some docs
Hope this helps
I honestly used the MSDN and thought it was very thourough. Its what I used to get up to snuff and build my WCF Rest Service but I am assuming you already looked there. This was my favorite link that I to this day, still have bookmarked.
Pertaining to your 4.0 vs 3.5. I almost always defer to later technology if you can, especially WCF simply because Microsoft has made things a little easier with things such as what Leon stated.
there are these videos for beginners and certainly very helpful.
you can learn about how to create services within minutes.
http://msdn.microsoft.com/en-us/netframework/dd939784
There is a video to show how to configure a rest json service as well.
I have been reading up on WCF and was looking for a good tutorial on
creating a WCF Restful service that returns Json. I cant seem to find
any that are really worth reading, does any have any ones they would
recommend for someone who just wants to start with the basics and
learn about WCF Restful service?
I had exactly the same problem last year.
Eventually, I worked out the steps you have to follow to create a JSON WCF Web Service - it is straightforward if you get each of the steps right, but finding an easy-to-follow walkthrough was tough.
Here's the walkthrough I created, clearly documenting what you need to do:
http://mikesknowledgebase.com/pages/Services/WebServices-Page1.htm
I follow this walkthrough whenever I create services, both for my ASP.Net apps or iOS apps.
Good luck !
I thought I ask the more exprienced Silverlight users about what they think is the best way to embed Silverlight user controls into an ASP.NET page - in special regards to stablish an easy way of communication between the conrols.
I have heard about services, query strings, etc. but I'd like to find out what has worked for you the best so far...
Take a look at WCF RIA Services. It provides a way for ASP.NET to expose methods and data entities and expose them to Silverlight automatically. RIA Services creates proxy objects on the Silverlight side and wires them up with WCF services without you having to do any work. It is pretty slick.
Here is a starting point. Beware: the learning curve is kind of steep. But it is rewarding once you get there.
http://www.silverlight.net/getstarted/riaservices/
Also, another thing to watch out for is that some of those articles refer to beta/CTP versions and some of the namespaces changed before it went to production.
take a look at the below article which uses event aggregation to communicate.. i found this useful..
http://blog.weareon.net/how-to-communicate-between-two-user-controls-using-event-aggregator/
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.