I'll start some lab prototypes on some of our Web App pages. We use a lot of Postback, ViewState, UpdatePanels, ModalPopup Extenders, all the ASP.NET usual stuff. It's good enough for most cases. But I wanna push things further...
I've been playing around with jQuery for some time now. I know what's capable of. I'm thinking of TRULY substituting the ASP.NET usual things by things like $.ajax(), $.get(), etc. No more postbacks. User interface? jQuery UI. I'm truly impressed by some plugins, specially jQuery grid.
I think it's the next step into Web UI. I mean, it's ALREADY the current step! I love the power of C#, but I'm not that impressed with the ASP.NET framework. I imagine that by doing that, I'll truly separate UI from Business logic.
However:
Should I really do it?
Should the code behind be only Web Handlers and Web Services?
What should I beware of?
How about security? How to implement it?
What will I gain? I know I'll gain some in performance, since postbacks in pages with too much data takes time because of the ViewState AND I'll be transacting only XML and/or the always light JSON format. But I imagine, as usual, there will be pain...
Where will the pain be?
I'll take it slow, anyway. But I want to ask you guys: what am I getting into here?
Before I reply, I would strongly suggest that you go for ASP.NET MVC Framework. It's a totally different kind of development than the Webforms. It's a step away from ViewState and that junk. This is where Microsoft is pushing all their efforts to and this is the only way right now to build much more scalable and interactive websites on the .NET Stack.
Should I really do it?
Yes. jQuery + Ajax are very good and would let you build some very interactive and usable websites. And the way things are going right now, truth to speak if you don't use the power of Javascript at the client-side, your website would like build in 1995.
Should the code behind be only Web Handlers and Web Services?
You should only use the handlers/services to improve the design of your page. You can't build your whole website only on that. The method is to create a page, and then improve it with the services. Avoid postbacks for small details. And improve speed by Ajax etc. Making a whole website on Ajax is not a good idea.
What should I beware of?
Technically you need to understand client-side coding and how does HTTP works over the internet. ASP.NET takes does that all under the hood, so you don't even need to know but if you are doing postbacks etc. then you should understand it's limitations etc.
How about security? How to implement it?
There isn't a lot to security in Ajax as long as you do the same stuff which you did for normal postbacks e.g.s CSS attacks, SQL injections, Anti-Forgery etc.
What will I gain? I know I'll gain some in performance, since postbacks in pages with too much data takes time because of the ViewState AND I'll be transacting only XML and/or the always light JSON format. But I imagine, as usual, there will be pain...
Where will the pain be?
The pain usually is the complexity. But complexity comes with flexibility. Traditional ASP.NET was taking care of everything without you having to interfere. but now you have to make up the request, send it to server, receive the reply and then update DOM accordingly. You have to deal with all of that but on the flip side, you can deal it in whatever you want.
Hope that helps.
I say yes. Postbacks are easy for the developer and horrible for the user experience. Don't make them suffer through heavy page loads just to toggle a box on the page.
But, you need to consider the time that it will take, especially since you might have to rely on more and more javascript code (which can be finicky if you are new to it).
I've recently done it on a large project and I'm glad I did it. I moved from full page postbacks to WebMethods and web services. Try to reduce state on the server which will help compartmentalize each request handler.
Look into asp.net-MVC it is most likely what you are talking about and implements jquery and JSON calls.
If you used PostBack and ViewState you might have done that for a reason. It allows for Components and Events. Thats something you will miss in ASP.NET MVC (you dont say you want to use ASP.NET MVC, but if you say ASP.NET without PostBack everyone will understand ASP.NET MVC)
I use ASP.NET and ASP.NET MVC. ASP.NET with postback comes into play if the project is realy more an application than a website (lets say nyt.com being a website and facebook being an application ).
Related
I'm bringing myself up to speed on Javascript, and I'm beginning to wonder if there is a purpose to using a Javascript framework like Backbone/Knockout if I'm already using ASP.Net MVC on the server side.
Since I'm trying to create a single-page browser experience, I can see why having a Javascript framework would be useful in general, but I'm beginning to wonder if I can't create a better experience just relying on AJAX server connections to update the page portions I want refreshed. I guess in general: what is the purpose of a Javascript framework?
While there are plenty of advocates for using Backbone and Knockout with MVC (Scott Guthrie was one of them with his SPA sample project), I find it overkill for a lot of my projects.
Lately I've been quite addicted to managing my JavaScript dependencies with Require.Js. It speeds up loading, helps me to modularize my code, and provides some handy uglification. However, at the end of the day, it is up to you to decide how much client-side architectural overhead you need.
As an aside, you may want to consider AngularJS as an alternative to Backbone/Knockout.
First off, I would say that nowadays most users expect dynamic experiences as well as responsive interfaces (responsive in terms of speed not the buzzword responsive). To achieve this, using JavaScript is generally the way to go. Usually you save yourself round trips to the server, which take up time and bandwidth.
As far as using a JavaScript framework, and choosing which one to use, that is really going to depend on the type of application you plan on building. For example, Backbone is great at structuring your application, whilst Knockout is great at handing user interaction. There is a bunch more variables that go in to this though, and there are plenty of blog posts which compare and contrast the various frameworks.
You will be hard pressed to get a truly interactive and dynamic web application without using JavaScript these days. The various frameworks will hopefully help you achieve the features you would like.
Javascript frameworks make SPA's and rich client side interactivity smoother, at the cost of more implementation than server side alone. The workhorse of Knockout is it's ability to update the DOM real time when models change, so you don't have to navigate and modify the DOM yourself. Its a tool. If you need it for your project, then by all means give it a shot, its probably worth the learning curve and learning javascript the object oriented way. If not, then you are wasting valuable slacker time by creating client and server side models.
How time consuming is it to move a website built using Webforms to one built using MVC?
I have an existing website built using asp.net webforms, but it is a little annoying. I want to use lots of javascript and ajax, but webforms makes this a little difficult. It tries to do too much for me, and thus makes it difficult to work with when I want to do things it doesn't expect.
As such, I've taken to only using the Page_Load event, and totally ignoring all the postback stuff - when I need to deal with submitting forms, I handle it manually from the Page_Load event with Request.Form["ElementName"], but most of the time I use javascript.
I've heard that asp.net MVC is much nicer to work with, so I'm thinking of porting my site over to this. Given that I am writing runat="server" only on standard HTML elements that I need to fill with data with .innerHTML =, how long will it take me to move over to MVC? Or is it a totally stupid idea to attempt this move?
well, as you've probably guessed, it's such a broad ranging question that it would be almost impossible to give advice on your individual scenario without seeing the scale of the existing codebase. However, there are many mitigating factors that you may want to think of regarding moving functionality across piecemeal, such as:
can I break down the existing functionality into discreet segments
does the exisiting site still require all current features
are there new features that I could introduce purely in mvc
do i need to extend the object model - EF code-first may give huge advantage via mvcscaffolding
the beauty with asp.net is that you can mix-match webforms and mvc together, thus you can chip away at functionality as required. Of course, there are so many resources on mvc on the web now, it'll be easy to get going quickly, so i'm sure you'll make good progress.
I think you'll really enjoy mvc - it's a no going back experience.
[edit] - there are a few interesting resources on the web that discuss the mix of webforms and mvc. however, the definitive one for me has to be scott hanselmans from a wee while back. still relevent in mvc3 as it was then:
http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
also:
http://www.aspnetmvcninja.com/general/mixing-asp-net-mvc-and-webforms
Short answer, impossible to tell here.
Long answer, it depends...
It depends on how many sites you have to rewrite, complexity of the site and your architecture.
If all your logic is in the code behind files you will have a long walk.
If your architecture separates responsibility with use of services and abstraction, a lot easier.
If I should walk that walk, I would look into porting the code bit by bit. I've done this with JSF and Spring MVC, and it looks like this is doable with .Net too.
http://weblogs.asp.net/rajbk/archive/2010/05/11/running-asp-net-webforms-and-asp-net-mvc-side-by-side.aspx
Wanting to improve your code and your skills is never a stupid move!
It is possible to use them both within the same application. It isn't necessarily advisable, but if you set an MVC project up, you can tell it to ignore page requests that map to your webform pages.
You can then start moving over functionality as you need it.
If there is likely to be functionality you need to be available across MVC and webform pages, then this is going to get complicated and you are probably best moving to MVC in one go.
Personally, what ever you do, start small and straightforward and if you can bit by bit.
It would have to be a rewrite, not a port. MVC sites are built very differently from WebForms sites.
MVC is not based on the ASP.NET request lifecycle. There is no codebehind; business logic gets called from Controller classes; data is encapsulated in Models which are then passed to Views. It's a totally different beast from ASP.NET.
And be warned: once you've made the switch to MVC, you'll never go back to the old world of ASP.NET! :-)
Good luck!
How would one go about creating a facebook-style "Like" button in C# ASP.NET without doing a postback? Are there any code examples or tutorials that you know of? I assume that would have to use asynchronous javascript. (this is a tough one to search for due to the Facebook keyword!)
This would have to work with .NET 2.o framework, SQL Server 2005 and VS 2005.
Thanks for any direction.
The technology you are looking for is AJAX. It is a fancy way to use JavaScript (specifically the httprequest object) and the HTML DOM to asynchronously do things on web pages.
Here is a tutorial specific to ASP.NET. It was written for .NET 1.1, but the principles are basically the same.
Suggestion: I really prefer the JQUERY AJAX implementation to the controls that ASP.NET has built in, even when working on ASPX pages. It just seems a lot more lightweight and has less magic going on behind the scenes.
I'm not completely sure what you're asking here but maybe an ASP.NET Web Service would be what you're looking for?
Here are a few links:
http://msdn.microsoft.com/en-us/library/ms972326.aspx
https://web.archive.org/web/20210304124019/https://www.4guysfromrolla.com/articles/062602-1.aspx
http://www.codeproject.com/KB/webservices/aspwebsvr.aspx
Like others said, you need to incorporate AJAX functionality and web services in your page for this to happen. One option is to use Page Methods. Another option is to write wcf services that directly emit JSON[via the ScriptService attribute] and use the callback mechanism to call these services, and handle their response in the success method to update the UI accordingly. Take a look at how to create wcf sercvices for emitting json.
I have before created a quick Ajax Framework for one of my projects. It was an ASP.Net Website (C#). There was not a lot of Ajax type functions so I just made a new Page with nothing in it and in the code behind file I put some code in the Page_Load method which would look for an action in the request and then call the appropriate method.
I am in the same scenario again and I am finding that I am tempted to do the same again.
I am letting the user create a new accommodation. Two of the fields that belong with accommodation are accommodation type and area. Both of these fields are maintained by the users so they can CRUD both of these fields on other pages. I was thinking that if the area or accommodation type did not yet exist it would be irritating to have to go to another page. So instead I want to give them the functionality of adding new areas and adding new accommodation types on the same form. So I have tickboxes for the accommodation type, when they click new I present them a textbox they enter the value and click add. It makes an Ajax call to the database to add the value and then a new tickbox appears if successful else an error message. Very similar for area except I will be using a drop down list.
This time however I am using some jQuery too. I am not that familiar with jQuery's Ajax libraries YET. My question is, "Is there a...
Better
Easier
Smarter
More Extendable
All of the above
way of doing this." If so can you please point me in the right direction.
Given that with VS2008 there's support for AJAX already built into the IDE (and with jQuery support coming), I think you'll find it tough to come up with something which is not only a better user experience but also a better developer experience.
The Visual Studio team not only have a lot of resources invested in making this work well, but they also know how to integrate features into the IDE, almost certainly better than you do (and with more access to do so, I suspect).
If you want to do this for fun (or as part of MonoDevelop, for instance), that makes sense - but from a productivity point of view, I'd just stick to Visual Studio.
I dont think you need to create an entirely new Ajax Framework. A lot of time and effort by many people has been put into other frameworks like the Asp.net Ajax, jQuery, and others. Take some time to learn what these frameworks provide for you and how you can use them. If you still find them lacking nearly all of them have ways to extend on their already built features.
I'm not going repeat what Jon Skeet said and I am sure twenty other people are typing; however, if you decide to roll your own, instead of using a blank ASPX page, look into creating your own Http Handler. In visual studo you can create you own quick and dirty handler. They have an extension of .ASHX. The benefit here is you avoid the overhead of the page object framework.
jQuery is in my experience a very good library with a lot of community support. Check out the jQuery IRC channel if you can't find what you are looking for in the documentation. We have an Ajax intensive application and it runs on jQuery as its core framework. We have been pleased with the results. If you are worried about size, Google hosts jQuery so your clients can cache it locally.
Alternatively, you may just want to create the proper HttpHandler(s) that will allow your client code to call server side resources without the overhead of a traditional ASP.NET Page class.
Check out this article from MSDN
I currently have a functioning in-house Windows Forms application which extensively uses the DataGridView control for data entry. There are some support issues which are expected when we roll this out to more locations, so one of our consultants has recommended putting together an AJAX application with substantially the same functionality.
I have used ASP.NET a bit in the past with the old model where basically everything goes to the server, but I've heard AJAX applications can be made more UI responsive than that.
So my question is, what's the best way to get started with AJAX, for someone who has worked mostly in WinForms C#?
The easiest way, but not neccessarly the best way is to get familiar with the UpdatePanel, which is part of the ASP.net AJAX controls.
You can use an ASP.net GridView control (which shares much of the Winforms equiv. functionality), wrap an UpdatePanel around it and you're away.
Further on from that you will want to get involved with web/wcf services to make calls from javascript to the server and update your UI based on the responce. That of course involved more time, effort and knowledge!
There are many gridview controls you can buy that will help e.g. One from essential objects is nice, not perfect, but very cheap compared to Telerik and other big names.
ASP.net is still a server based technology, but with the inclusion of ASP.net AJAX calls to the server are easy and with jQuery updating the UI is getting easier!!
Hope this helps
What you're wanting to do isn't very hard especially with Telerik's or Infragistic's controls, but as the previous commenter stated, they aren't cheap. They are probably worth the price if you don't want to spend the time rolling your own responsive and editable grid.