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.
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'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 aim to try use DevExpress web server controls (which are awesome) in an ASP.NET MVC project (some articles I read on 'net seems to indicate the two can work well together).
I'm eager to start a new project using ASP.NET MVC, and I have been reading up a lot on ASP.NET MVC lately, but I'm not sure if I should invest a project in it. My concern is that it may turn out to be like LINQ to SQL, which is essentially been killed off since MS will not be providing updates.
Is ASP.NET MVC a viable solution to invest in my case?
Yes definitely ASP.NET MVC or any other MVC framework is worth learning. MVC pattern is all about seperation of concerns and helps you to keep your code clean.
If you like Devexpress control too much you could be disappointed because there is no server side control in ASP.NET MVC. But if you want to learn Web's underlying mechanism,HTML, Javascript , clean code, TDD ASP.NET MVC is a good way to go.
Learn first, experiment later
Asp.net MVC is a great development platform for building web applications, so it's definitely worth your time to learn it through and through.
But I suggest you first learn MVC framework and build at least one semi complex app with it and then start experimenting with mixing MVC with web forms controls. It is possible but as much you think you will gain you'll probably loose more. So I would be a bit reluctant and advise you not to match these. At least not on a Greenfield project.
In other words: presumably knowing Asp.net web forms would you suggest someone to heavy use dynamicly created user controls in their web pages if they're just about to learn the technology of Asp.net web forms? Probably not. Or mixing web forms with ASP pages on a greenfield project...
Instead try finding great either MVC-friendly server extensions or client-side libraries that will help you create rich web apps like ExtJS (I don't work for ExtJS llc, but I used the lib on a project in the past and liked it a lot). Using something like this you won't loose stuff from MVC and gain great user experience and rich functionality.
Seeing how you're asking the question on this site, I'd say YES!
DevExpress has a bunch of MVC specialized controls, that use Ajax to get data from the server via callbacks. You can see demos of the controls here:
http://mvc.devexpress.com.
I am not sure if you can use the web forms controls, my understanding is that you can't.
Also, regarding LinqToSql, you don't have to use that. I am using NHibernate for the data layer and it works very nice with MVC.
I worked with asp.net and web forms for more than 5 years and at least 1 year with the DevExpress controls for asp.net, but now I love MVC so much that I think I don't want to go back to the web forms anytime soon.
Hope this helped.
I'm a big fan of what ASP.NET MVC is doing, on many levels.
I'm about to take part in re-build of a very highly trafficked website, and I'm not which framework would be best (if any).
The site will need the following:
To support Javascript-heavy, highly interactive pages
But at the same time, provide underlying semantic HTML for search engines
Support multiple languages
Be skinnable
Expose a RESTful web-service API for partners
As far as I can tell, there's no reason not to use ASP.NET MVC for this.
I can present semantic HTML and layer Javascript on top using jQuery.
Multiple languages can be catered for using Resource files (same as at present).
Skinning can be done with CSS (it won't involve changes to the markup).
I can centralize business logic so that the Controllers and the WCF web-service use the same code.
But are there potential drawbacks to using MVC that I haven't considered?
I don't want to be the guy who picks a technology because it's cool but finds later down the track that it isn't very suitable for the job.
ASP.NET MVC is not good when all your doing is making a website that needs server-side code (but that's also true about ASP.NET also).
In your case I think MVC would be a great way to go. MVC has proven itself on high traffic websites (e.g. this one). However you must remember that MVC is new and changing. A library may not exists to do a specific task which means you'll have to write that code yourself.
Good luck on your rebuild!
You're good to go with MVC given what you've said about your project.
As far as I'm concerned, ASP.NET MVC is really only NOT good for situations where you have a large codebase in WebForms (meaning you have a lot of ASP.NET user controls, custom controls, etc). It's also not good if you are going to have people working on it who don't know what it's all about. Other than that, it's a pretty nice technology.
My two cents:
ASP.NET MVC is a great option but there is a little learning curve involved, so make sure your project plan/timeline has this handled. There might be developers on your team who might not be comfortable working with ASP.NET MVC, and this can cause possible delays (a lot of developers are still working in ASP.NET 1.1!).
#Alex: Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
IMO the idea of using controls in ASP.NET MVC doesnt make much sense. You can create a treeview control using jQuery easily. Classic ASP.NET server controls carried a lot of baggage (viewstate etc) and hence ASP.NET MVC did not use any of those controls (though you can use helpers).
Finally, ASP.NET MVC is an alternative, not a replacement to Web Forms. I would not use ASP.NET MVC as it is still evolving, and my team is not very comfortable with it, but I guess slowly more and more programmers would shift to this (better) option.
I do not like ASP.NET MVC because of following reasons:
1.
Ugly routing API, there http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx
is description of what is wrong.
By the way, friendly urls can be easily implemented without mvc
http://demo.liveui.net/bugtracker/Tasks/7
2.
Poor object model. It is proved that good software should consist of reusable components. There is nothing that can be reused in ASP.NET MVC based web site. For example, if you implemented smart drop down list once it will be difficult to use it again (even on the same web site).
3.
Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
If I were you I would try to find some CMS and customize it for WebSite needs.
To responses:
YES. I know about ASP.NET controls disadvantages, but the question is about ASP.NET MVC. One can write a book about what is good and what is bad in ASP.NET but I do not think it is appropriate to discuss it here.
There are better ways of implementing MVC without using asp.net MVC. I have done it in the past, even before asp.net MVC came live. MVC is a pattern, not a technology, I do not understand why some people call it a Technology. You can separate all concerns by removing the code-behind from webforms and create your own controllers and routers and you will still have the advantage of the webform controls, etc to which most asp.net developers are used to use. asp.net mvc is nice for people whom do not really have the time to properly create an MVC app in a webforms environment and also to those whom do not have the time to architect a better solution. in conlcusion, asp.net mvc is good but there is a much better way of doing it and finally, MVC is NOT a technology.
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.