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.
Related
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!
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 ).
Regarding those articles:
Update Panels and JSON Alternatives
Why ASP.NET AJAX UpdatePanels are dangerous
PageMethods vs UpdatePanels
I think AJAX UpdatePanels can't be the appropriate way of implementing a partial page renders for big application or good scalable ones.
So I hope I could find a dedicated sources for search things.
I know how to integrate JavaScript with ASP.NET
But what I'm looking for is a very specific resource to teach me to do whatever I could have done with AJAX UpdatePanels.
I had a (thankfully brief) affair with UpdatePanels, and since I've started using jQuery http://docs.jquery.com/Tutorials and jQuery UI http://jqueryui.com/
I have never looked back. I know this isnt a book but I found that most of the stuff on the website is pretty well written and can get you started pretty fast :)
I think the idea is you want to start looking to have your client consume server data with as little asp.net heavy handedness as possible.
I think this works alot better in ASP.NET MVC than it did in previous platforms.
We currently have a WinForms application that we want to slowly migrate to a web application.
One screen is a time sheet entry system that uses DataWindow and is very slow and buggy.
Anyway, the time sheet screen has five sections that are saved in real time. A finished time sheet needs 2-5 of these sections.
Currently, the system runs SLOW. Some of our remote offices barely have a frac-T1.
So I want to redesign that screen using ASP.NET MVC2 and even provide some enhancements like autocomplete (which it currently lacks), etc.
Any suggestions on best practices for a form that I KNOW will be high-volume AND run on possible slow networks?
Currently, there is a lot of round-trip traffic because each section of the time sheet saves when they tab out of a field. I would like to avoid this but I do admit the partial saves are cool.
Any suggestions or tips are appreciated.
Thanks
This is a tough one to give a definitive answer for - whichever option you take there will be trade-offs and compromises.
Personally I would suggest OOB Silverlight 4 + WCF.
You get the one-off hit of downloading the Silverlight app1, but once they have that installed the only traffic you should have is the data and messages sent to/from the web services. Cutting traffic down to just pure data+messages and eliminating the HTML will reduce congestion a lot.
You could use AJAX from ASP.Net or ASP.NET MVC, but you still have the hit of downloading the page each time the user wants to fill out a time sheet. AJAX can also be a little chatty, especially when it comes to providing functionality like autocomplete. It can also be considerably more difficult to get a nice to use UI when using ASP.NET/MVC, with SL you will find it easier to emulate the UI functionality of the current Winforms app. And in my experience development of rich web apps is considerably faster in Silverlight than ASP.NET.
In any case, it may be best if you code up some demos using both technologies, and run them to see exactly how they perform in the worst offices, that will be the only way to know for sure which is best.
1 The traffic hit of downloading the Silverlight app can be reduced by using SL4, make the app an Out of Browser one, shipping out the XAP file to the users and using sllauncher.exe to install it (this is bread and butter stuff for sysadmins). This does make it harder to update the SL app, but you could just do it this way in the offices where network traffic is particularly bad.
php/lamp vs. asp.net mvc: the only factor involved isn't licensing cost. The team plays an important factor, of course this depends on your pre-existing skills, but there will be a higher overhead of development + infrastructure by chasing the platform you are less used to.
The project might not give the expected results because of that, and that'd be a bigger problem than saving a small %. Pre-emptive strike: you don't need to use ms sql with asp.net MVC, so "the database license doesn't make it a small %" isn't a valid argument.
As for hints check the answer I posted to this question: Scalable application with ASP.NET or Google AppEngine. Additionally:
you don't need to load all those tabs at once. You can retrieve the tabs as the user selects them. This will make the initial load time faster (at the cost of a hopefully v. small delay when opening other tab for the first time). If appropriate for the scenario, you can hold the already opened tabs at the client, so the extra hit/delay only occurs the first time the extra tab was opened.
Currently, there is a lot of round-trip traffic because each section of the time sheet saves when they tab out of a field. I would like to avoid this but I do admit the partial saves are cool.
You might already be doing so, but you can use change detection to make sure its only posted when the user actually made a change. Additionally you don't need to send the whole tab, you could send just the changes to be made.
I want to develop ASP.NET C# based MMOG (Massively multiplayer online game). I would be using ASP.NET Ajax control kit, jquery and MS SQL server 2005.
Q.1)How feasible .NET 3.5, ASP.NET with C# in handling thousands of users simultaneously.
I would also incorporate ASP.NET ajax based chatting system with chat rooms alongside the MMOG.
Q.2) Do you know any of the sites (MMOG) using ASP.NET ?
Q.3) What are the best practices for Chatting System as mentioned above?
ASP.NET and MSSQL 2005 definitely have no "built in" scaling problems. You will have to take care to build you application right and be prepared to dish out some money for proper hardware.
See for example the hardware setup that is scheduled to tackle the stackoverflow load.
ASP.NET can handle it with the proper server configuration, hardware, and performance considerations when creating the application.
I tried to do some googling and didn't find anything right away, but I'm sure that there are some out there.
For the chat piece you might look at a product such as CuteChat that already exists and has been tried and tested for a long time.
I would think about using Silverlight instead of the AJAX-based stuff. From a UI perspective you'll be able to do a lot more.
ViewState will end up being your end game raid boss unless you disable it or switch to ASP.NET MVC.
Maybe today you start with a html/javascript/jquery UI and tomorrow you throw on a fancy Silverlight or Flash UI.
AjaxControlToolkit is pretty bloated and kinda hard to customize. With an MMO, speed is going to be a priority, so you'll want as much control over your postbacks as possible.
You also might try looking into Silverlight for your front end. It integrates well with the .NET environment, and would be a lot easier to develop your interactive pieces with.
Plenty of bigass websites running ASP.NET. I'd HIGHLY recommend using the new MVC framework, as it reduces the complexity of ASP.NET websites greatly.