ASP.net MVC vs ASP.net Webforms

[sao123]

For the last several years(~6) I have been a ASP.net WebForms developer using C# and ADO.net with SQL Server (also some Javascript/Jquery, but is less relevant to this discussion).

What I was hoping to find out from the seasoned MVC developers, is why it is a superior platform in the realm of Data Driven enterprise web applications.

Now I have taken 2-3 courses on MVC to learn how to do some mvc programming, but from my perspective, I cant see how MVC would be better suited for the tasks I do.

I do see that the MVC platform is well suited for ASP.net Web API restful services. URL Routing allows it to make very efficient use of how to many URLs to serve up large numbers of different JSON data streams, such as in the world of Weather/GIS/etc.

I see how MVC gives a more rapid application creation platform, and is much better in the unit testing than webforms, because the UI is much more easily seperated from the Business Logic, Data Access Layer, and Presentation Layer.

Even though my personal preference is to write C# ADO.net code using SQLDataReader / SQLDataWriter, etc I can see the benefit of using the wizard generated Entity Framework. And if I could write those manually by C#, I would be tempted to write EF to SQL Stored procedures.

But what I dont see is how MVC is better at doing rich web pages for complex data UI pages. All the classes and demo's I have seen are all simple sites, many of which are the MS Contoso University or using the MVCMusic store example. Most of them are very simply forms, which in my world of enterprise data do not equate.

From the simple world of using postbacks (not present in MVC) to create cascading dropdowns, ListBox Pairs with Left Right Move Item Controls, to using the MS AjaxControlToolkit Extensions to using GridViews, Editable Gridviews, Data Entry Gridviews, all of which make inserting ASP.net controls in any column using the TemplateField a breeze. And i'm doing all this writing code. I'm not using the designers, wizards, or drag and drop controls, I completely write my own ASPX files, code-behind files, and script files.
MVC doesnt have any serverside controls, and that makes rich enterprise data driven web clients seem difficult to near impossible to me.

Is webforms the superior tool, or is there something about MVC which I am just flat out missing?

Edit: fixed some spelling/grammar mistakes

 

[purbeast0]

i don't have much to contribute, but i had no clue that there was such thing as "ASP .NET MVC" until i clicked on this thread then googled. i thought you were just referring to the design pattern of model-view-controller.

in general though, with mvc, you mentioned some of the overall benefits. you can have different layers, all that don't care about each other or need to know about each other. i personally find it easy to maintain for these reasons, in all aspects, some of which you already touched on as well with the testing example.

 

[KB]

There are loads of discussion about it on the web:

http://codebetter.com/karlseguin/2010/03/11/webforms-vs-mvc-again/
http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari#option
http://stackoverflow.com/questions/1035642/asp-net-mvc-vs-webforms-speed-and-architecture-comparison


My Input: I have done Webforms for years too and have struggled with why asp.net MVC is the next logical successor. Webforms does so much for you, from instant paging in GridViews to automatic deletes/updates when using datasources. And there is nothing better than not having to worry about restoring state (like dropdown list values, font colors etc) across post-backs. I can build a fully functional site in 1/2 the time using Webforms as it takes to do in MVC, yet the development world is going toward MVC as am I.

The reasons for this include what you said:
-MVC platform is well suited for ASP.net Web API restful services.
So much development is going into mobile sites that use json APIs for speed and reduced bandwidth. A lot of new web development is on the client javascript side instead of the server making ASP.Net almost unneeded. Server could be Node.js or php it doesn't matter.

-URL Routing allows it to make very efficient use of how to many URLs to serve up large numbers of different JSON data streams, such as in the world of Weather/GIS/etc.
The URLs in MVC are more search friendly too.

-MVC gives a more rapid application creation platform, and is much better in the unit testing than webforms, because the UI is much more easily seperated from the Business Logic, Data Access Layer, and Presentation Layer.
This is a big reason. Automated testing of webforms is difficult and prone to issues.

-MVC is more efficient because it is more stateless. ASP.Net webforms has a lot of overhead due to its attempt at being "stateful" in a "stateless" http request. For example ViewState can grow to be half the page size if used incorrectly (although you can turn viewstate off for most controls). MVC allows you better control over html markup so you can send less html output to the client. Asp.net webforms go through a large event cycle, init, preload, prerender, load, render etc. while MVC just renders making it faster.

 

[clamum]

MVC platform is well suited for ASP.net Web API restful services.

Is there any site(s) I can read for more information on this? I've used ASP MVC in the past on a couple of smaller websites but I really have no f'ing clue what "Web API restful services" means.

 

[nakedfrog]

Is there any site(s) I can read for more information on this? I've used ASP MVC in the past on a couple of smaller websites but I really have no f'ing clue what "Web API restful services" means.

Look up REST APIs. They're getting pretty widespread now, I'm seeing a lot of newer software migrating from WSDLs to REST APIs.

 

[sao123]

Is there any site(s) I can read for more information on this? I've used ASP MVC in the past on a couple of smaller websites but I really have no f'ing clue what "Web API restful services" means.

Most traditional websites have as their source some sort of database and a Data Access Layer and Potentially a Business Logic Layer, to go with their Web Gui front end.

the short and simple explanation is a Web API Restful service is a a web based back end data service which exists fully independent of any UI for the data.

Why is this important? Generally speaking, in MVC and other tightly coupled webstack technologies, the layers are tightly integrated, making back end layers not friendly to reuse for multiple applications.

so now lets talk specific examples.

if you were building MVC sites, Lets say, maybe a weather page. You would have a controller, a model, and a view to create a page to deliver some sort of data to the user. Now if you are familiar with the routing of MVC, an example of a routing could be something to the effect of

http://WeatherDomain.com/{Region}/{City}/{Forecast}?Days=value
or
http://WeatherDomain.com/{Region}/{City}/{Radar}?ZoomMiles=value

which each respectively would grant you a value=3 day forecast for some city in some region, or take you to the radar display for that city zoomed at value=150 miles.

Your MVC page is infinitely tied to the Entity Framework Model which you use to get the data from your database in CRUD operations. So maybe you can reuse the EF back end for your MVC mobile site, but when you write your NATIVE Android/Ios app, or other non .Net webstack site (JSP/PHP/Angular.js), you can no longer use the EF backend you have written, you have to re-write the entire DAL all over again.

So... along came restful services (in whatever your technology of choice -
Soap, Jax-WS/Jax-RS, WCF, .Net Web API) enter the web service.
So instead of using the MVC routing to display a full page, you now use the MVC routing to return either an XML or JSON object with all the back end data, and whatever UI implementation you have gets that data stream to interpret and display.

So now...

http://WeatherDomain.com/NorthEast/Pittsburgh/Forecast?Days=3

instead of displaying a web page now returns JSON object:

{"City:Pittsburgh",
 "Forecast:[
    {"day":"Monday", "Weather":"Cloudy", "Temp:75" },
    {"day":"Tuesday", "Weather":"Rainy", "Temp:65" },
    {"day":"Wednesday", "Weather":"Sunny", "Temp:85" }
]}

but you still have to have another UI in whatever environment to present the information. It might be your original MVC web page.
The point is to have a back end data site which functions as fully independent service API, and can be used to send data to ALL of your gui interface.

A single back end data service for all your full rich web clients, your native windows/linux executable apps, your mobile web environments, and your native mobile executable apps (android store/ios store) greatly simplifies web structure, AND provides a better infrastructure for Traditional Websites + Mobile Sites + Mobile native Apps + etc AND increasing security by having less exposure to the database itself. Aka finally you can have full separation of concerns for the front end from the back end, which is something MVC attempts to do, but only partially succeeds at.

i would suggest a book to read.
http://it-ebooks.info/book/3285/
http://it-ebooks.info/book/3648/

 

[brianmanahan]

i don't have much to contribute, but i had no clue that there was such thing as "ASP .NET MVC" until i clicked on this thread then googled. i thought you were just referring to the design pattern of model-view-controller.

it's hilarious that .NET really didn't do MVC until about 10 years after Struts came out

 

[Bacon1]

You would want to use a javascript framework like angular, react or even jquery for your front end stuff.

We do lots of angular + mvc (very minimal / light weight) + web api and its great. Basically the only thing you use your mvc for is the initial layout/index page, and everything else is just angular small plain html templates for your angular "views/pages".

Web API is the main benefit of using the new stuff, its great and by removing all the old webform stuff you can use some very nice javascript front end libraries.

So basically, at this point I'd say skip MVC and Web forms, just use plain html + angular or react (or jquery + MVC partial pages) and Web Api.

 

[sao123]

Angular, Kendo, Ember, React, MVC, JqueryUI, Knockout, JSfiddle,
why is it that none of the MVC based frameworks is able to easily replicate the powerful Editable DataGrid control that Webforms Gridview provides.
not only can i have an editable gridview, I can have cascading dropdowns in each row.

thats not to say it cant be done... but it cant be done EASILY.

 

[purbeast0]

Angular, Kendo, Ember, React, MVC, JqueryUI, Knockout, JSfiddle,
why is it that none of the MVC based frameworks is able to easily replicate the powerful Editable DataGrid control that Webforms Gridview provides.
not only can i have an editable gridview, I can have cascading dropdowns in each row.

thats not to say it cant be done... but it cant be done EASILY.

there are other things that you can do that with, then integrate into whatever framework you're using.

we use slickgrids at work (with angular as our framework), but it is pretty bad for really large datasets. there is another one that my coworker told me about but i forget the name. you can also do what you're asking with bootstrap if you would like, which is more of a UI framework.

i just googled angular grid directive and saw quite a few hits that you could just add to your project and use.

 

[dannydiscus]

All great information, thanks

 

[brianmanahan]

we use slickgrids at work (with angular as our framework), but it is pretty bad for really large datasets.

maybe it's angular's bidirectional digest cycle doing that?

i'm going to start taking a look at angular 2 shortly, and compare with react

 

[purbeast0]

maybe it's angular's bidirectional digest cycle doing that?

i'm going to start taking a look at angular 2 shortly, and compare with react

it might be, but i'm talking data sets of over 100k rows with over 50 columns.

 

[clamum]

Most traditional websites have as their source some sort of database and a Data Access Layer and Potentially a Business Logic Layer, to go with their Web Gui front end.

the short and simple explanation is a Web API Restful service is a a web based back end data service which exists fully independent of any UI for the data.

Why is this important? Generally speaking, in MVC and other tightly coupled webstack technologies, the layers are tightly integrated, making back end layers not friendly to reuse for multiple applications.

so now lets talk specific examples.

if you were building MVC sites, Lets say, maybe a weather page. You would have a controller, a model, and a view to create a page to deliver some sort of data to the user. Now if you are familiar with the routing of MVC, an example of a routing could be something to the effect of

http://WeatherDomain.com/{Region}/{City}/{Forecast}?Days=value
or
http://WeatherDomain.com/{Region}/{City}/{Radar}?ZoomMiles=value

which each respectively would grant you a value=3 day forecast for some city in some region, or take you to the radar display for that city zoomed at value=150 miles.

Your MVC page is infinitely tied to the Entity Framework Model which you use to get the data from your database in CRUD operations. So maybe you can reuse the EF back end for your MVC mobile site, but when you write your NATIVE Android/Ios app, or other non .Net webstack site (JSP/PHP/Angular.js), you can no longer use the EF backend you have written, you have to re-write the entire DAL all over again.

So... along came restful services (in whatever your technology of choice -
Soap, Jax-WS/Jax-RS, WCF, .Net Web API) enter the web service.
So instead of using the MVC routing to display a full page, you now use the MVC routing to return either an XML or JSON object with all the back end data, and whatever UI implementation you have gets that data stream to interpret and display.

So now...

http://WeatherDomain.com/NorthEast/Pittsburgh/Forecast?Days=3

instead of displaying a web page now returns JSON object:

{"City:Pittsburgh",
 "Forecast:[
    {"day":"Monday", "Weather":"Cloudy", "Temp:75" },
    {"day":"Tuesday", "Weather":"Rainy", "Temp:65" },
    {"day":"Wednesday", "Weather":"Sunny", "Temp:85" }
]}

but you still have to have another UI in whatever environment to present the information. It might be your original MVC web page.
The point is to have a back end data site which functions as fully independent service API, and can be used to send data to ALL of your gui interface.

A single back end data service for all your full rich web clients, your native windows/linux executable apps, your mobile web environments, and your native mobile executable apps (android store/ios store) greatly simplifies web structure, AND provides a better infrastructure for Traditional Websites + Mobile Sites + Mobile native Apps + etc AND increasing security by having less exposure to the database itself. Aka finally you can have full separation of concerns for the front end from the back end, which is something MVC attempts to do, but only partially succeeds at.

i would suggest a book to read.
http://it-ebooks.info/book/3285/
http://it-ebooks.info/book/3648/

Thank you very much for the detailed explanation. I am a little more familiar with REST APIs since my original post; actually I worked with them a little bit at work recently and wrote a simple .NET app to call some functions exposed through a REST API site. I will say it's kind of a pain to call and receive data from REST APIs, even using the RestSharp library. It just seems like it should be MUCH easier to do that.

Anyway. So, basically RESTful services are like web services (I'm fairly familiar with the latter)? I mean, it's basically just a way to remotely call functions that return data, like web services do?

 

[Broheim]

Anyway. So, basically RESTful services are like web services (I'm fairly familiar with the latter)? I mean, it's basically just a way to remotely call functions that return data, like web services do?

A RESTful web service is just a web service that follows certain conventions to make it predictable. There should be no gotchas and surprises for the person using the web service if they are already familiar with RESTful web services.

 

[nakedfrog]

Thank you very much for the detailed explanation. I am a little more familiar with REST APIs since my original post; actually I worked with them a little bit at work recently and wrote a simple .NET app to call some functions exposed through a REST API site. I will say it's kind of a pain to call and receive data from REST APIs, even using the RestSharp library. It just seems like it should be MUCH easier to do that.

Anyway. So, basically RESTful services are like web services (I'm fairly familiar with the latter)? I mean, it's basically just a way to remotely call functions that return data, like web services do?

I've only used RestSharp a little (to make it easier to implement some of this stuff in a .Net 3.5-based project), I like the .Net 4.5 System.Net.Http stuff more. Also handy to just use the built-in "Paste JSON as class" functionality in Visual Studio to get going quickly.
In answer to your question, essentially, yes.