Is there any ajax toolkit for asp.net MVC
As MVC does not have ViewState or the Web Forms postback model the AjaxControlToolkit will not work with it.
There is a project to do this (http://mvccontroltoolkit.codeplex.com/) but it's not yet released.
There are numerous blogs where have got different controls working but to be honest I'd suggest looking at jQuery and its plugins (http://www.jqueryui.com/). MVC lends itself far more naturally to these, it is not control-based.
Here's another resource talking about this: http://www.hanselman.com/blog/ASPNETMVCPreview4UsingAjaxAndAjaxForm.aspx
In addition, ASP.NET MVC lends itself quite easily to making your own amazing ajax controls, especially when combined with jQuery.
The emphasis in ASP.NET MVC is more on HTML and client-side code when talking about user-control similar to those in the AJAX Toolkit - you may like to check out the excellent http://www.jqueryui.com/ for some good client-side controls.
Related
I am going to start work on a SaaS based application. I need to decide whether to go with ASP.Net MVC or web forms application. Through various posts I came to know that both are good, they are not replacement of each other and so on.
Also, I know traditional web forms method, I am not aware of MVC, I need to learn it first.
Please guide me which approach is better.
Thanks,
Vijay
i can just share some of my experience as i have worked on both
i preffer asp.net MVC over Asp.net because of the futile layer of abstraction that Asp.Net has over basic HTTP architecture
the user controls in asp.Net induce unnecessary markup
ease of using ajax in asp.net mvc compared to updatepanel(in advanced senarious)
support of razor type syntax increases productivity
no overloading by things like viewstate
because everything is managed by the programmer soem of the typical issues that arise in asp.net like the problems in dynamic controls are no longer present
so if you ask me go for asp.net MVC
There is no right answer here. I prefer MVC but if you already know ASP.Net WebForms it probably is easier to stick with that.
I am currently learning ASP.NET, and I have trouble figuring out how ASP.NET MVC should be used compared to webforms.
I usually used PHP to make websites, and had to learn a lot of things about webforms : postbacks, callbacks, web controls etc. But the way I understand it, all of those are not supposed to be used in MVC applications, which seems strange to me since those represent a lot of features of the ASP.NET framework. I would like to confirm the following :
Should I forget everything about postbacks and callbacks when using ASP.NET MVC ?
Should I forget most web controls ? (I mean controls starting with asp:). Most of them seem not to be usable because there isn't any "form" tag like in webforms.
In that case, would it be right to say that ASP.NET MVC is a bit like well-organized PHP ? Webforms works in a totally different way from PHP because of the postback mechanics, but it seems to me that MVC applications can be designed pretty much the same way as PHP.
Are .ascx user components still used in ASP.NET MVC ?
What about the script manager, and the AJAX framework ?
Should I use Javascript the same way I would with PHP ?
Thanks in advance !
Should I forget everything about postbacks and callbacks when using ASP.NET MVC ?
Yes
Should I forget most web controls ? (I mean controls starting with asp:). Most of them seem not to be usable because there isn't any "form" tag like in webforms.
Yes
In that case, would it be right to say that ASP.NET MVC is a bit like well-organized PHP ? Webforms works in a totally different way from PHP because of the postback mechanics, but it seems to me that MVC applications can be designed pretty much the same way as PHP.
Not really
Are .ascx user components still used in ASP.NET MVC ?
No
What about the script manager, and the AJAX framework ?
No
Should I use Javascript the same way I would with PHP ?
Maybe
ASP.Net MVC is completely different from WebForms.
The comparison to PHP depends on how you use PHP.
I see lot and lot of advantage in using Knockout.js in my MVC project but before going for it I want to make sure if there are any implications of using the same, or precautions to be taken while using Knockout.js
KnockoutJS is included by default starting with ASP.NET MVC4, so it's safe to say that you're going to see it a lot in ASP.NET MVC going forward.
Ultimately there aren't any conflicts of any sort that you have to worry about with Knockout with ASP.NET MVC. It doesn't conflict with any of the DataAnnotations or other auto-scaffolded JavaScript.
You don't get any knockout scaffolding for free (not like DataAnnotations and jQuery validation) so you only use it in instances where you explicitly code it into a view or partial yourself.
I use Knockout heavily in MVC4 and in Node.JS applications and it works great in tandem with jQuery - never ran into any issues with it on either platform.
I'm wondering about one thing - as we know, the MVC pattern is stateless (it doesn't use the ViewState, so we use only HTML controls), but if we use them in WebForms as well, it'll become stateless too ? so, by doing this, we are getting closer to the MVC pattern ?
You get closer to one aspect of MVC i suppose but its still a night and day difference.
MVC is fundamentally about the model view controller pattern, not what kind of controls your using to write your code. Unless you implement an MVC pattern within webforms (which people did a lot before ASP.NET MVC was released) and migrate away from the postback model in webforms then your platform is still considerably different.
If you want to do that then just use ASP.NET MVC.
ASP.NET WebForms is stateless too. All HTTP communications are. ViewState is just a way of preserving some state by hidden form fields which' values are encoded.
There is nothing stopping you creating your own hidden fields in MVC to make it 'kinda stateful'.
No we don't use HTML controls in ASP.NET MVC. We use HTML helpers. There's a big difference.
I think you're confused about what stateless means. All web development is stateless, in so far as the server sends down a page to the client and then forgets about it.
.NET tries to make it "easier" by using ViewState and Session, but MVC and Web Forms are stateless.
MVC is an architectual pattern. It can be implemented in any language/framework/environment (although some make it easier than others.)
I don't know why you would attempt to apply MVC to webforms when all the work has been done for you by Microsoft to implement MVC in ASP.NET with ASP.NET MVC...
As with any software models, there isn't necessarily a hard-defined line between fundamental principles. I've been developing applications with loose implementations of MVC in WebForms for years.
The lack of pseudo-state (I won't give WebForms the credit for actual state, the web is stateless) in MVC is one of a number of aspects of the ASP.NET implementation of it, it is not part of the actual MVC pattern.
On top of all this, I can see why people miss Web Controls and want to use them in MVC. But why would you want to use HTML helpers in WebForms? If you're willing to do this type of groundwork then you probably should be using MVC.
I've been tasked with making a prototype web application, and i'm debating between using ASP.NET WebForms or the new ASP.NET MVC.
There is a commerical ASP.NET UserControl that i would like to use that gives me 95% of the functionality i need (and it does it in an AJAX-y fashion). But i've heard that since ASP.NET MVC doesn't use ViewState, it can't run these WebForms-based controls.
So, is that true or false?
I'd really like to use this commerical UserControl, but i want to use ASP.NET MVC if i can, and only if ASP.NET MVC is not going to give me much trouble when trying to use the WebForms-based control.
Traditional WebForms and MVC aren't mutually exclusive; you could run both of them in the same site. For an explanation of how to make this happen, see this post by Scott Hanselman.
So you could, for example, create WebForms-based page(s) to leverage the commercial control, and use MVC for everything else. You could also set up a simple test to see if the control can operate without ViewState -- making it OK to use in MVC -- and fall back on the hybrid approach.
It probably won't work. There is no viewstate, postbacks (in the Webforms sense) or page lifecycle which most commercial controls rely on in some fashion.