Comments on Deep Shah's Blog: Asp.Net MVC vs Asp.Net Web Forms

i really found this post helpful...thnk you

2012-02-29T17:47:14.726+05:30

i really found this post helpful...thnk you

I think that web forms has played its role in maki...

2012-02-25T18:59:03.497+05:30

I think that web forms has played its role in making coding in the world of http an easy task, but only in enterprise level. Technically speaking, it promoted an environment and methodology a bit strange for that world, the single form model and page lifecycle. Web applications serve content that is requested using an endpoint and that content consists from smaller pieces that do something, menus, banners, forms, articles, datalists etc. Technically the source for each is different and the user will interact with only one each time, so it should really be separated from other modules. Web forms break that by serving them as one, even if using usercontrols...they are served as one...they postback as one, in the same page, that is a file, even for redirection the 'page' must be recreated etc. Viewstate, page lifecycle, unique control iding system, state restoration was invented to cover only the methodology of web forms, its not an http matter. It was something done for the first time but i feel a bit misslead from web programming. I was stuck in the server implementation and gave less to serving web content. Web dev is simpler when scripted directly. That is me though. Keep walking.

I think that web forms has played its role in maki...

2012-02-25T18:58:16.563+05:30

Hello There, You can totally Create separate busi...

2012-02-25T12:22:26.697+05:30

Hello There,

You can totally Create separate business and data libraries MVC does not stop you from doing it.

Custom reusable sections of page in MVC are called partials. You can create them very easily and use them across your application.

There are many options, one of them is, create HtmlHelpers to do it

We have build an application with MVC which has a datagrid on almost every page. We use jqGrid for showing the grid. We integrate it with MVC using jquery and JSON.

You can serialize the model on the page in the worst cast if you really want to a functionality like view state. Else you can use hidden fields for store singular values like identifiers.

Thanks

Deep Shah

Im an ASP MVC and Spring MVC developer. Its cool, ...

2012-02-11T20:37:02.756+05:30

Im an ASP MVC and Spring MVC developer. Its cool, nice architecture MVC but I will summarize as this:

If is a Website without much cluttered GUI, simple forms, list, etc the way of HTML and few jquery plugins so use MVC.

If is a Web Application, with cluttered or complex GUI, you need custom components(forget here jquery plugins, some are good but some are useless) and state, Webforms is the way to go.

I'm relatively new to MVC but I've used We...

2012-02-10T20:14:29.379+05:30

I'm relatively new to MVC but I've used Webforms since .NET 1.0. There are parts I like and I can see how it can help a novice developer but I don't like how inflexible the pattern is and I'm concerned that it will limit the expandability and flexibility of the application. Generally speaking, I like to create separate business libraries and data layers in n-tier fashion - my code behind pages are very lean and clean and I use controls to separate code if I need to for SOC and SRP.

My questions about MVC are the following:

1. Could I create business and data libraries with MVC or is everything forced to reside in the model layer?

2. Can I create custom web controls or ascx controls with MVC and reuse them across web pages?

3. Where do I add custom code for presentation? I don't want to add functions in a view as that would remind me of ASP with hmtl and code interspersed.

4. It sounds like you can't use datagrids with MVC. I really don't want to build my own sortable datagrid:-)

5. What do other developers use in MVC to mimic viewstate? I suppose I could use an asp.net hidden control and parse the values myself but that's what viewstate does, right?

Hi, I notice how many people have ALWAYS used webf...

2012-02-10T02:31:26.861+05:30

Hi, I notice how many people have ALWAYS used webforms wrongly and how the call MVC a technology. MVC exists even before many of us were born. I have developed MVC applications well before asp.net MVC came live, so to me it is not new and indeed, although they have done a good job, it still lacks power. HTML can be controlled only when there is a clean separation of concerns, something that many asp.net webform developers DO NOT KNOW how to do because they just keep on using what microsoft told them to use, a code-behind model which is not very good either. You can totally remove the code behind from a webform and create your own controllers and routing. Extension-less URLs can be achieved by using libraries such as intelligentia. Then, you have a total separation of concerns and you have an MVC (Model View Controller) application without loosing the features that most developers are used to use, such as Custom user contorls, etc. my point is... if you really are a developer, you will have done MVC apps even before asp.net MVC.

How is writing if(IsPostback)....else.... any more...

2012-02-09T02:55:23.822+05:30

How is writing if(IsPostback)....else.... any more complicated than writing [HttpPost] and [HttpGet] as attributes of the MVC methods? You are still doing the same thing. You call one method on post, and another on get. Are the parenthesis in the if/then really that much of a problem?

Regarding url routing, outside of SEO (a programmers worst nighmare thanks to retarded search engines), what benefit does passing "directory" parameters to a controller have over passing querystring parameters to a page? In both cases, you're instructing some page/method/function/etc to handle the request. You could argue it would help in switching platforms or something (honestly, if you switch platforms, is that your biggest concern?) but in both cases, you are requesting a very specific resource.

Finally, regarding viewstate, turn it on when you want an easy way to handle page/control state and turn it off when you need the extra performance boost and want to code around the cases where data needs to be repopulated.

-Justin

ViewState is a very useful component if used prope...

2012-02-04T05:39:30.917+05:30

ViewState is a very useful component if used properly. It can be manipulated in many ways to adjust to small applications to large web forms. To say that ASP.NET MVC is faster than Web Forms is down-right wrong. ASP.NET Web Forms out-weigh MVC performance-wise.

With ASP.NET 4.0, you have URL routing for RESTless and SEO friendly URLs. It's very simple to take advantage of this feature in your Global.asax.

If you're a powerful developer / architect, you will realize that a well-versed web forms developer will outperform (development-time-wise and performance-wise) a skillful MVC developer. Done it for over 8 years and am pretty familiar with MVC... too much control taken away from you. I tell my program what to do, I don't let it tell me how to build my architecture.

Hello Deleo, One of the readers on a different po...

2011-11-06T13:44:39.580+05:30

Hello Deleo,

One of the readers on a different post wrote this and I guess, it applies to this conversation as well:

"I think it's hard to understand what Deep is talking about without having made transition from ASP.NET with all its complexities to another platform (MVC3, Rails, Grails, you name it). The thing is, Telerik is following ASP.NET best practice which is about putting an elephant in a China shop. I was working quite extensively in ASP.NET and now I moved to MVC3/JQuery/JSON and guess what - things just work. You don't have to keep in mind that a control put extra code and alter ids and name on the client side. The programming model is so much better it makes me wonder what kept so long in ASP.NET world"

Hello Deleo, Me too enjoys constructive conversat...

2011-11-06T13:31:53.262+05:30

Hello Deleo,

Me too enjoys constructive conversation and I can tell you one thing I am enjoying this one!

I think we have to agree to disagree with each other.

It seems like you agree with me on the design front, and on point number 2.

About 5, putting static methods? Well I don't know about other but I surely don't like putting static methods anywhere. Static methods are signs of poor design.

Point 6 and 7, You need to understand that one does not develop all projects from scratch. We have to inherit some projects and in such projects, people have not followed the best practices because of which you have to deal with a hell lot of crap code and bad design.

I would agree that this can happen with MVC as well but since it forces the developers to follow good design practices the changes of bad MVC code are very little.

Whatever I have mentioned in the post are real problems with Web Forms and I can certainly tell you that 80% (if not more) of the projects out there suffer from these problems.

First I like to thank you for your response, I do ...

2011-11-02T18:18:00.650+05:30

First I like to thank you for your response, I do love a good conversation :)

A webform does not force a developer to use a specific pattern, which can be a downside if the developer or team is inexperienced or plain stupid. Given these two terms, you can really frackup the mvc pattern as well. Although it does give the developer something to think about and many errors in design can/vcould be avoided.

2) Yes, some use third party frameworks such as Telerik and you have no exact control of the HTML, this is true in Webform as well as MVC.
5) You create it as same as you would with MVC. Perform a AJAX to server. You have to define static methods in codebehind which will catch the call though, and parse it to JSON.
6)You are answering your own question. You should never put code in codebehind that is reliant on postback. Write your codebehind with the mindset that postback does not exist. Bind everything onLoad method and use HttpRuntime.Cache as often as you can. You can also limit this GET/POST in webforms, you just dont know how.
7)Really? you cant understand why viewstate was invented in the first place? Webforms have existed for a very long time, where there were needs to preserve state. Later Microsoft invented control state, which is used instead of viewstate to hold critical state of a control. Microsoft have turned viewstate on as default because of compatibility. Any skilled web developer turns this off. Have you ever seen the attribute AutoeventWireup= true? Have you ever changed this to false? Well, you should ALWAYS turn this off unless you need compatibility to old ASP code. This as with viewstate is turned on by default by Microsoft.

I am an old webform developer that have not yet seen the great benefits of MVC, that is true. I don't write an article saying which is better, because I dont know MVC that much. Same should you. Do not put webforms down when you clearly lack the knowledge of webforms. I understand enough of MVC and its difference to Webforms to state that neither is one's successor. You use webforms and MVC for the same thing, although in some scenarios you should choose MVC over webforms.They both have their strength and weakness.
Please dont take this as trolling, if you do, please excuse my writing. I meant this as purely feedback, constructive. In your future technology articles you might want some experience to backup your theories :)

Hello Deleo, Here are my responses: 1) WebForms ...

2011-10-22T13:16:26.304+05:30

Hello Deleo,

Here are my responses:

1) WebForms code behind class is a mess. People write all sort of code in the code behind class. The fact that WebForms does not force you to have any separation of concern itself leads to poor design in most cases.

2) Lot of times, people use third party controls like Telerik and Infragistics. With these controls you can't always have full control over the HTML generated.

3) If a framework is difficult to unit test what does it highlight? It highlights that, its poorly designed.

4) I would agree with you here.

5) Tell me something, with webforms, if you had a state dropdown (dropdown control) needs to be updated when a country is selected and we wanted to do this using JQuery only, how much could would you have to write. Hod difficult/easy would it be?

6) Posting back to the same page and then writing code to identify whether its a postback or not, is boiler plate code. This is, another example of not having separation of concerns. Checking "IsPostBack" is framework code, why should my code behind worry about whether its postback or not?

MVC can do AJAX using a GET or POST does not have to be a GET request. I can totally control which Action to call in the GET/POST request. I don't have to keep checking whether its a GET/POST request and perform an action based on that decision. In fact, I can also control that certain actions are only available over POST request and certain actions are only available over GET request. This is done by simply adding an attribute over the action names.

7) Why would a framework enable something by default (ViewState) that is actually bad and then someone has to turn it off explicitly? Question is why have it in first place. MVC has no view state at all and developers are spared from turning it on or off!

I might be a "not very experienced webforms developer" but to me, you look like a very well versed webforms developer, who wants to overlook the benefits of MVC and does not want to move on.

I can't say I agree on your points, and here i...

2011-10-21T15:13:13.265+05:30

I can't say I agree on your points, and here is why:
1) You say seperation of concern: Webforms have exactly that, but you as a developer have to do it. Webforms does not force you to do anything like MVC does because Webforms is not a pattern. Webforms gives you the developer the freedom to use whatever you want. There are no limitations in webforms for coding SOC.
Consider Webforms as your View and Model, leave all business and connection layer to something else.
2) Total control of HTML: If you dont know how to control your HTML in Webforms, then you are not very bright developer. You can use pure Xhtml and never use any asp net controls. In ASP .NET 4, you can even determine how the ID tag is formed.
3) Unit test, you got me there, webforms are difficult to unit test but not impossible.
4) SEO, webforms can use the same routing as MVC and give the same SEO, so this point is bull...
5) Integration with third party javascript, Im not even gonna answere this silly one..
6) No postback, well true in some ways. MVC does perform client callback, which is AJAX which is some sort of postback, just with GET rather than POST.
7) No Viewstate...Hahahahah, you can easily turn off Viewstate and every good programmers should do this on default in webforms..

After reviewing this artivle you seem not very experienced in Webforms, and your points are not all that thoughtful, but thanks for the input :)

Agreed. However in 99% of the cases GET is used t...

2011-07-30T22:57:08.617+05:30

Agreed.

However in 99% of the cases GET is used to load the Page for the first time. And when one fills the form and submits the information it submitted over the POST to the same page. Hence, although for the sake of arguing, one could think that IsPostBack is nothing to do with GET or POST requests, the truth is IsPostBack is mostly used to differentiate between the GET and POST requests.

Over and above it the point here is that the code that gets executed when IsPostBack=true is almost always completely different from what gets executed in IsPostBack=false condition.

For e.g. lets say we have to render a form where Address needs to be entered by an user. When the page gets rendered for the first time i.e. IsPostBack=false/GET request we get all sorts of reference data i.e. load the list of countries (from the DB) in the drop down and stuff like that. When information is filled and posted back i.e. IsPostBack=true/POST request, we usually write code to save the address information and not bother about filling the country dropdown.

With MVC we can clearly specify what should happen when a GET request is executing and what should happen when POST request is executing. We do not have to keep checking whether its IsPostBack=true or IsPostBack=false. This for me reduces some boiler plate code.

"Do you still feel IsPostBack has nothing to ...

2011-07-29T21:39:37.065+05:30

"Do you still feel IsPostBack has nothing to do with GET or POST request?"

Yes - because GET or POST can happen on the first attempt to retrieve info from a page (POST via cross page postbacks). I'll let MS explain:

During a cross-page postback, the contents of the source page's controls are posted to the target page, and the browser executes an HTTP POST operation (not a GET operation). However, in the target page, the IsPostBack property is false immediately after a cross-page post. Although the behavior is that of a POST, the cross-posting is not a postback to the target page. Therefore, IsPostBack is set to false and the target page can go through its first-time code.

Hello Vassil Terziev, Thanks, Personally, I have ...

2011-07-24T22:29:05.324+05:30

Hello Vassil Terziev,

Thanks, Personally, I have nothing against Telerik controls. Whatever I have posted are my real experiences.

I am a big fan of Open source software. MVC comes integrated with jQuery, there are thousands of open source plugins for jQuery which do almost anything that you can think of. I have not tried Telerik's offering for ASP.NET MVC because till now I didn't see a need to use any paid MVC components. However that's just me.

Giedrius Mereckis,

You are right, I have not done much Web Forms development. However, I feel I understand Web Forms approach just fine.

Let me explain it again, As you said IsPostBack tells us whether page is entered/rendered first time or not. When the Page is rendered first time a "GET" request is sent to the server. In this request IsPostBack will be set to false.

When a post back event occurs for e.g. lets say user fills the form and clicks the submit button, information is submitted to the same page using the the HTTP POST method. In this request IsPostBack will be set to true. Do you still feel IsPostBack has nothing to do with GET or POST request?

I can understanding, for long time Asp.NET web forms developers moving to Asp.NET MVC3 might be a bit overwhelming, but trust me, if you want to develop fast Web 2.0 applications, MVC is going to be the way forward.

Thanks

Deep Shah

Doesn't sound like you have done a lot of web ...

2011-07-22T00:41:18.232+05:30

Doesn't sound like you have done a lot of web forms programming. IsPostBack has nothing to do with Get or Post requests, it refers whether the page is entered first time or not (PostBack). I still prefer WebForms for web applications due to the object-oriented feel, component based approach(if done right). MVC feels like functional programming to me and I prefer it for content websites with.

Good post! ASP.NET MVC does offer its set of advan...

2011-07-19T03:04:55.532+05:30

Good post! ASP.NET MVC does offer its set of advantages over ASP.NET WebForms.

I know you don't like Telerik's WebForms offering but you should check out our MVC extensions (http://demos.telerik.com/aspnet-mvc/). Would be interesting to get your take on those as they were done from the ground up and in the "pure" ASP.NET MVC way. Hopefully they are a better fit for your projects and maybe you'll like them more:)