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.
Related
Currently we have a new menu item to our existing asp.net web forms application.
We have decided to go with MVC for this.
Please note that we have to share the same masterpages, css and Jquery files. We are currently planning to render the view inside a div in our aspx pages.
Is there a better way to accomplish this?
What are the limitations of our approach?
Can we leverage the MVC test cases in this approach?
Thanks
MVC is a stateless, disconnected architecture, you can not access the master page or aspx controls directly in the controller as aspx.cs does, secondly it is not possible to use the classic asp.net master page with mvc.
The things you can re use from existing project are:
UI Templates (design)
JS files
CSS files
Business Logic
Database
You can't use same master pages. You can't reuse ASP.NET MVC for some parts of your webforms view and vice versa. Either your view is completely on webforms or on ASP.NET MVC. And theoretically even mix of webforms with mvc in one web application could be problematic, but practically possible (see below point 1). So generally answer to your question is no.
If you are looking to ASP.NET MVC, you should think about step-by-step migration of your project to it.
Actually there are a couple of possibilities how to migrate
Mix in one project ASP.NET web forms and ASP.NET MVC. Technically it is possible. But it is some kind of hack. Your transition will be seamless but you can't your ASP.NET views. I will not recommend it. You can find this approach here http://www.devcurry.com/2013/05/adopting-aspnet-mvc-enhancements-in.html
In one solution use different projects for your webforms and mvc projects. In fact these are 2 different web application which typically could have common authentication, and there is question with webforms state. To solve problem with authentication you need create separate web service for it, which will be used by both. To solve problems with session state, use distributed caching for both, and try to change thinking from webforms state to caching, because mvc is actually stateless. Then for particular views you can redirect between views of both portals
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.
The application consists of lots of runtime generated grids and charts.
Coloring of gridcells will be required for some threshold based on data.
also there will be use of ajax for sorting, paging and exporting on gridviews.
Should I go with webforms or can mvc provide some benefits over webforms when struggling with
preinits, event bindings and viewstate for runtime grid and chart generation.
Pre-thanks for your opinions.
There's nothing that you described that ASP.NET MVC wouldn't be able to handle and then some.
Having said that, you should consider a few things.
The webforms page life cycle that you're describing is not used in ASP.NET MVC.
There is no viewstate, there is a concept of a model that you use, but viewstate is gone.
If you're using third party controls for your grids and charts you need to make sure they are compatible with ASP.NET MVC. They may not be, especially if they utilize viewstate.
You don't get charts and grids out of the box with MVC, you have to implement the syntax yourself, or buy some controls that do.
One of the things about ASP.NET MVC that folks don't seem to mention too often is that for many things, more work and development time is required over a standard ASP.NET application.
ASP.NET MVC gives you a lot of control over your application but that means you forgo a lot of the RAD conveniences that standard ASP.NET offers.
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.