I have developed a webapplication in both ASP.NET MVC and ASP.NET Webforms and i'm wondering isn't Webforms following the rules of the MVC Pattern just the as ASP.NET MVC is?
I mean we have the .aspx file which holds the visual (HTML and JavaScript) and then the code behind file which controls the user interaction and data for the .aspx file. Then we could make a Repository lager for fetching and doing stuff with data.
Isn't this the same as following the rules of the MVC Pattern? View for visual, Controller for controlling user interaction and data for the Views and the Model fetching and doing stuff with data?
I know ASP.NET MVC and Webforms handles Postbacks and URL handeling differently, but im not comparing the two ASP.NET techniques, but the MVC Pattern in generele for the two techniques.
ASP.NET Webforms is definitely not following the MVC pattern.
In MVC you have three elements, the Model, the View, and the Controller.
In ASP.NET Webforms, you have your Page (codebehind and the markup are compiled into a single object, not seperate), and whatever data is being shown. You really have no controller. You make a requrest directly to the page rather than a controller and the page is responsible for both working with the data and rendering the page. Definitely not seperated like MVC would be.
Just the fact that you're not using the codebehind in your aspx page should give you a hint that there are some pretty substantial differences between MVC and webforms... You aren't using the codebehind, are you?
Not to mention how hard it is to test a Webforms page.... You are testing your code, right?
You can indeed use an MVC pattern with Web Forms, but all you are doing is adding additional classes or layers to the postback. The previous answers here are coming from a purist point of view that is more clear separations built into the technology. But, there is nothing preventing you from using different classes to represent the Model the View and Controller and only have your WebForms bind to the View. All of the communication is still done on postback, but it is still technically MVC and still the correct pattern to use.
Reference:
http://msdn.microsoft.com/en-us/magazine/ff955232.aspx
Related
I was wanting to ask the following about mvc to have a better understanding.
1 What is the difference between the way webforms and action controllers work.
2 How should one coming from a webforms background convert the page_load etc button clicks etc into mvc methods and events. Its this understanding that I am lacking.
3.How do i fill controls before I was used to setting the datasource but see allot of controls using the foreach on the front end is that really code separation?.
4 I will be developing a form designer in .net webforms I was used to using panels and loading controls but I see it will be neater in mvc by using partial views would that be my best course of action. I am a senior asp.net webforms developer with over ten years experience.
I have been watching plurisight videos but they center on using sql express not server.
A lot of help material you can get online about this topic.
Your first question about the way webforms and action controllers work -
In webform, you specify the code-behind file of your .aspx page and the code-behind file is the master of that page now. The browser hits the .aspx and the code behind file manages the work.
But in MVC, no view file is approached; the path is matched to the respective controller and action and the action handles it. Any controller can access the View of any other Controller. There are Shared Views which are common for every controller as well.
I strongly suggest you to read at this link and this codeproject article.
Some major points will be this :
You wont have the RAD (Rapid Application Development) environment i.e. the drag drop support for Controls, page viewer in case of Razor, etc.
You wont have the basic server controls Gridview, Repeater,etc in MVC. None of the controls in MVC are bind to any controller. You can neatly pick the desired elements using Javascript and play with them.
You get full control over the HTML
What I feel is that MVC is more flexible and jQuery-able as compared to Webforms
All the best!
I've been watching a video on Scott Hanselmnn teaching MVC 2 tricks/tips. He mentions how MVC 2 by default uses ASP.NET Web Forms view engine to render the output of the views; he mentions that the web forms view engine is a little slower than it could be for MVC 2 since it generates a control tree and then outputs the HTML to the page (I hope I said that right).
I was wondering what he meant by web forms generating a code tree before outputting the HTML to the page. Does anyone have insight on the view engine of Web forms and the steps of the rendering process works for ASP.NET and MVC2?
In Web Forms, the HTML is generated by a hierarchy of controls, each of which needs to be called upon to render its HTML and each of which contributes to the Page ViewState. In addition, a lot of events are fired by Web Forms (Init, PreRender, etc) during its life cycle, and each control in the hierarchy also fires similar events.
In MVC, the process could theoretically be much simpler, as you don't have a deep hierarchy of controls, you don't have ViewState, and you don't have the need to fire events. However, MVC "piggybacks" off of the ASP.NET framework, and so behind the scenes, a lot of the Web Forms stuff is still there, although it's not needed.
ASP.Net WebForms was all built around the idea of "Faking" a persitent, stateful model around the stateless nature of HTTP. The idea was to give WinForms developers a familiar environment to work in, i.e. Controls, Events, Etc...
In order to do this, the markup is parsed into a collection of objects in memory that you can then reference like you would a control in WinForms:
TextBox.Text = "I hate viewstate!";
Each Control is added to a collection of Controls that represent the page to be sent back to the client. When it comes time to build the response, the engine walks through the tree collection of controls and asks each control to Render itself to the output stream. The result is what you get in the form of an HTTP Response.
In MVC this is an unnecessary step because those controls are never referenced. MVC embraces the stateless nature of the web, and instead maps posted form variables directly to Models for use by Controller Actions.
I don't have real understanding of the MVC model or Architecture yet but what I read and see is that it separated the 'Concerns' that is the presentation UI and logical code, right? But I know that WebForms Architecture also has a code behind model which then separates the code and UI.
Is there something else also in MVC which further separates the stuff around?
The main difference between MVC and WebForms is that in WebForms it is the view that receives the request (/foo.aspx), while in MVC it is the controller (/controller) which will manipulate the model and choose the appropriate view to render. Another important difference is that all the HTTP Context stack (Request, Response, Session, ...) has been abstracted behind abstract classes and interfaces in ASP.NET MVC which allows for better separation of concerns and unit testability in isolation. You also have far more control over the generated markup in ASP.NET MVC in contrast to WebForms where the markup is essentially generated by server side controls.
Code-behind is specifically what makes UI tightly coupled to business logic in WebForms -- the code-behind is part of the UI.
Using controllers instead of code-behind is one of the primary ways in which MVC decouples these concerns.
The easiest way to think about this is that the .aspx and code behind are essentially two different views of the same component, the UI. It's completely possible to use code behinds with MVC (if you're using the webforms view engine), but both the view and the code behind are considered part of the UI. The controller is a seperate entity, as is the model.
Code-behind is specifically what makes
UI tightly coupled to business logic
in WebForms -- the code-behind is part
of the UI.
Only if you choose to let it.
Business logic will not be coupled to UI if you choose to have seperate business layer/tier and implment an appropriote UI layer pattern such as MVP/MVC/MVVM.
Id argue a n-layer design with an MVP pattern in webforms can offer even greater seperation of concerns than asp.net MVC but requires alot more upfront design.
Asp.Net MVC forces better seperation out of the box. Its baked into it.
This is good for developers who might not know any better. With webforms it is completly up to the architect/developer to select the level of sepearion required, a double edged sword because if you're experienced with the platform can do some great stuff, but if your new to it or coming from a classic asp style of development you may make a mess of it without some guidance.
Biggest plus I see for asp.net MVC over webforms isnt soc, or testability (as they can be acheived in webforms) it's the ability have better control over markup (if you need it) and the more web centric focus (again, if thats what you need).
I was wondering, whats the best way to handle common HTML controls in ASP.NET? I mean, ASP.NET server controls generate too much crap inside the code so I rather use common controls.
But how about databind and how to manage those common objects correctly (such as combobox, textbox and so on)?
Don't forget that you can always set runat="server" on any control - that includes standard html form controls such as <input> and <select>, and also other elements like <div>. Anything, really.
This means that you can regain control of the html output in your WebForms pages quite effortlessly - as long as you don't need viewstate or any other more advanced databinding/state managing that ASP.NET normally handles for you.
That said, learning to use the ASP.NET MVC Framework is not a bad idea, since it helps you regain control of much more than just the html output. Generally, creating a page in ASP.NET MVC takes a little more work, since there are no drag-n-drop controls like gridview, textbox or even repeater. Instead, you use html helper methods and regular foreach loops, which means you have to type a lot more code. However, the MVC framework is designed so that you won't have to repeat much code anyway.
If you're concerned about the html markup generated by the WebForms ASP.NET engine, i suggest you take a look at ASP.NET MVC. It's purpose is specifically to give you the control you need over the generated html.
If you don't want to start learning ASP.NET MVC, ASP.NET 4.0 WebForms gives you more flexibility in the generated HTML (such as enabling the ViewState for a specific control only, setting the html id's etc.).
As for the databinding, again if you study MVC in depth and start thinking in terms of action -> result you can gain a lot more control and flexibility.
Later edit: I forgot to mention Razor, the new ViewEngine under development at microsoft. It's currently in beta and only inside WebMatrix, a very stripped down 'getting-started type' development platform for ASP.NET. MVC combined with the very clean code you can write using Razor will be in my opinion an important trend-setter in the web development world.
There's a reason ASP.Net controls generate all that "crap". It's so you can databind and manage those objects correctly. Using standard html controls is useful when you don't need direct databinding or if you have no need to manipulate the control through server-side code.
The best way to handle common HTML controls in ASP.Net is not to handle them directly. By using them to handle data and functionality, you're basically neutering .Net. You might as well go back to classic ASP.
Are there some things I cannot do with ASP.NET MVC?
Things that are only possible with ASP.NET WebForms,
or extremely much easier with WebForms?
We consider using ASP.NET MVC for a new project.
But I wonder if there are some obvious things we will not be able to do with ASP.NET MVC when compared to WebForms, or places where we will have to spend a lot of time with ASP.NET MVC.
The biggest one would be using existing 3rd party controls on your form. Most of the inbuilt controls are pretty easy to reproduce, but if you have a pet 3rd party control, you might have to host that on a regular (non-MVC) aspx page (luckliy this is supported).
Likewise, "web parts"
Also - the feature where ASP.NET uses different html for different clients (mobile, etc) becomes... different; you wouldn't want to do this by hand, but in reality most clients now work with standard html, so it is less of an issue in the first place.
Some things like i18n via resx files need extra work than is in the vanilla MVC template, but the samples are there on the internet.
One point... MVC is licensed only for MS/ASP.NET; so one thing you can't do (without violating the terms, as I understand it) is to run it in mono/Apache - but IANAL.
Now consider the things you can do with MVC, that you can't (or are hard) with vanilla:
routes instead of pages
automated input resolution (action arguments)
proper html control...
...enabling jQuery etc for simple AJAX
separation of concerns
testability
IoC/DI
multiple templating options (not just aspx/ascx)
re input resolution:
public ActionResult Show(string name, int? page, int? pageSize) {...}
will pick "name", "page" and "pageSize" off (any of) the route, query-string or form - so you don't have to spend lots of time picking out request values.
re templates - aspx/ascx aren't the only templating options. For example, see here; or you can write your own if you like... The view is not tied to ASP.NET controls at all.
Validation is not as easy as in WebForms. In Webforms you can add a validator and just set a property that enables clientside validation. You can localize the errormessage. The localization works clientside and serverside.
There is no out of the box clientside validation in MVC and you need to find a way to localize clientside errormessages.
Localization itself is different. Ressources obviously by default dont exist per page, because there is no page. But there is a good way to have ressources per view.
I still did not check, if it is possible to set SSL-required per folder.
EDIT
The story is different with MVC3. There is a good validation support now.
There are still things that are not implemented in MVC. The biggest issue for me is a complete implementation for donut cashing and partial cashing. There is some improvement in MVC3 in this area but it is still not complete. Anyway stay tuned: the MVC team seams to be aware that this is something they should work on.
The big one is Controls. User Controls are not available with ASP.NET MVC. I have even gone so far as to try using code like this:
new Label().RenderControl(...ResponseStream...);
No dice.
Of course, as a part of that, there is no need for view state, so that isn't in there.
Server controls do work, though.
As Marc said, third party tools and (serverside) webcontrols cannot be used. So slapping something together quickly by dragging and dropping a few controls on a form (like a grid and a dataaccess control) is no longer an option.
But with the codegeneration etc. you can still make something quickly. And you still have the above option if you need something quick.
I think view-state is non existent in MVC. You will have to track your own view state in some other way than the built in view-state in non MVC projects.
EDIT:
According to comments: "Getting rid of ViewState is an advantage not a disadvantage". – Craig
ASP.NET Ajax is not working with ASP.NET MVC so no UpdatePanel (due to lack of postback). Fortunately there is built-in ajax (Ajax.Form) which can be used to perform partial updates not to mention jQuery which is shipped by default with the Visual Studio project template.