ASP.NET MVC and data heavy applications_问答_开发者

I've been learning ASP.NET MVC for about a month now and I'm certainly sold on its benefit开发者_高级运维s but I realize it is not applicable to all situations.

I've read in several places that ASP.NET MVC is not ideal for data-intensive applications:

Example 1: "Data Driven Application – life would be MUCH easier using WebForms if the application is data heavy"
Example 2: Nick Berardi's book suggests that you side with Web forms if your application is "data-heavy"

Can someone clarify as to why ASP.NET MVC is ill-suited towards data-heavy applications and why Web forms are more appropriate? Also, where does one draw the line between data-heavy applications and other applications? Are we talking quantity of data (millions of records) or are we talking large data models?

I would really like this clarified as well, as I have found the exact opposite to be true, and I think stackoverflow.com is evidence of the suitability of MVC to data-driven apps.

I didn't bother reading much of the second link, but the assertions in the first are not qualified, and many of them seem wrong to me. The stated weaknesses of WebForms, though, would be enough to drive me from using it for a data-intensive app:

UI logic coupled with the code, and thus is hard to separate.
Harder to unit test, so difficult to employ TDD.
Heavy page sizes due to view state management.

The stated weaknesses of MVC are quite flimsy:

Not event driven, so maybe difficult for people who know only Asp.Net Webforms to wrap their minds around it.
Third party control library support is not that strong.
No ViewState(this is also a strength).

The first one can be seen as a plus as much as minus. The second is just wrong as MVC apps can leverage traditional server-side controls if they wish, as well as make use of the rich library of client-side controls and libraries. The third, well I don't think I even need to speak to that one...

You have to be wary when reading articles like this on the internet - they sound authoritative and comprehensive, but where is the meat? Why are the stated weaknesses an issue? It is not enough to just throw opinion out there as fact. They should be backed up with metrics, such as when using platform x over y, developers unfamiliar with either platform were able to complete an application 30% faster, or platform x resulted in 25% fewer lines of code, or fewer levels of indirection, or whatever.

The idea that RAD is a plus is another one that bears careful examination: RAD is fast until you want to do something a particular control was not designed for, and then you hit a brick wall. It is a leaky abstraction and when it fails, you are suddenly confronted with the full complexity of understanding the design framework and code of the given control. This can be quite a setback, and the source code for these controls is not always available.

Doesn't make much sense to me. They might be speculating on the difficulty of creating many models if you have lots of different types of data, or perhaps the relative difficulty of creating web forms in MVC.

However, ORMs (such as L2Sql, EF and Subsonic), model binders, and form generators (I can't find the link right now) pretty much hose those arguments.

Frankly I don't buy it.

I believe that these authors are talking about the ability to drag/drop data controls onto the page such as GridViews, FormViews, and other databound objects.

Say you have a database for your IT department, with a table for computers, a table for printers, one for software, etc. The UI for this is a very simple data management system, essentially a glorified MS Access.

Rather than writing an elegant web app, with beautiful HTML and a class library, you could simply create a quick/dirty WebForms app by dragging your data sources and controls onto the page in Visual Studio.