ASP.NET MVC suitable to complex web application?

Question

Last week , my boss ask my team to evaluate ASP.NET MVC, for next project. all of us working with webform since .NET 1.1, we have no MVC experience before ,but all of my colleague are interest in ASP.NET MVC ,But no luck , our finally answer is NO.

Because: 1. we believe although you are ASP.NET Guru, you can build a complex application in short times. But if you change to ASP.NET MVC, the development time will take longer, every things need to using html helper, no web control, and many question ,keep opening the Firefox Tab with ASP.NET forum for ask How-To question.

1. we had see many times people say MVC provide better project management , but if it is a complex web site, i can imagine there are hundred of <%=%> TAG in one page, and keep open controller to see what to return, and keep opening model to see the logic.

I can say , it is not MVC bad, it because Webform is strong enought.

Answer 1

Among many benefits to using MVC is the removal of the viewstate hog.

If your Webform app is really large and uses a lot of server-side items that bloat your line with viewstate, then MVC may actually help you, even though it may take longer to develop.

On the flip side of that, be on the lookout for .NET v4.0 which will allow you to control viewstate on the control level instead of just on the page level. That will make MVC even less palatable overall.

Answer 2

I think you're right that it will take your team time to adapt to the new technology, and this will take extra time in the short term.

I wouldn't start using MVC in production until are some decent books out and the team has had a chance to read the books and play with the technology. Otherwise it seems your dev team will spend a lot of time watching screencasts and fishing for documentation.

Answer 3

It will take several weeks to change over to a new technology, or a "way of thinking".

With MVC, you have to get away from old ASP.NET Forms way of thinking "complex web application" in that "how many pages we have, over 300 pages! that would be huge!". You change the view of your entire application. You shift from old thinking of "what page need to create next" to the MVC way of thinking of "what function do we need to implement next".

For example, I myself took control of a project that has over 3300 files in the 'web' project alone (plus the 11 supporting assemblies). One thing that I am architecting is how MVC will drastically cut down the number of physical files down to around 310 or so. How? Because I am moving away from "here's one page. Here's another page." to a "here's the function I want to implement" way of thinking.

By looking at pages as the function you are trying to accomplish, you instead start abstracting pieces of that page out into common functionality.

MVC can greatly scale with this way-of-thinking because now you have a template for the way you want it to look, you just need to implement another "function" to change the look of that View (html) you want to render. No 2nd page, no additional controls, etc.

Now, as for "no web controls" as you mentioned: again, this calls for a different way of thinking. There is the HtmlHelper that is used for basic rendering and encoding. I use the same concept with an abstracted class called MyProjectHelper that renders my "functions" onto the page (functions=code).

For example, I always created a Server Control for my DisplayNames in the past. This allowed me to control the way that DisplayName was shown, especially with a switch to Facebook Connect and other things. With MVC, I no longer use a "server control", but a "function" on a ViewModel to render that text: CollegeProjectViewModel.RenderDisplayName(). Since this is only part of the UI layer, this will render the Anchor as needed with any options I wish (of course, the abstract is inherited by the CollegeProjectViewModel that picks up on the "basic" text rendering).

MVC's power lies in the ability to no longer require a "webpage", but instead "functions" or methods of what you want to do with your site. By changing to this way of thinking, you really can scale with as many method you create on your Controllers. It really speeds things up on a mass scale IMO.

Answer 4

I came from webform development (just like you), from 1.0 up until 3.5. When I discovered MVC (CTP), it took me about 6 months to convince my peers (and my boss) that it is the way to go.

Some of the highlights of my arguments:

1. Full control of HTML
2. TRUE AJAX (instead of update panel)
3. Possibility of using jQuery exponentially increased
4. No VIEWSTATE
5. Separation of concern
6. .. and .. (drum roll) ... faster development

Although #6 is a little bit subjective, but I did try to prove it by building prototypes. For my prototype, I built a simple dashboard web app, using both webform and asp.net mvc. I showed my peers and my boss the result, as well as the complexity of building and maintaining each one. In the end, we migrate our main methodology from webform to MVC.

It is true that it takes a while to "unlearn" some webform paradigm. But once you get it, MVC is so much easier to pick up and you can run with it.

In webform, yes it is powerful, but often in large projects, we spend a lot of our time trying to "customizing" or "coercing" a server control to behave and perform like the way we want it - and as complexity of the system goes up, the complexity of this customization also goes up exponentially.

TRUE AJAX is also quite difficult in webform. UpdatePanel has its role, but nested update panels has its own share of problems as well.

For me and my peers, it boils down to the ability to control our HTML/code/AJAX - instead of automatically generated 90% by the framework but we have to spend a lot of time and effort to get the rest 10%.

ASP.NET MVC, combined with jQuery, and your prefered biz tier framework or ORM, is extremely powerful. So far to date, we have released 3 production releases with ASP.NET MVC and they all perform well - heck take a look at stackoverflow.com (it uses MVC btw).

Answer 5

I worked on a MVC project at my last company for 6 months (we were using the CTP builds and eventually the beta builds). Initially, it was fun and exciting and it felt like we were really on to something. Like a lot of .NET developers out there, we were tired of the leaky abstractions of Web Forms.

However, as time progressed, we started to question our decision. The UI development was taking like 80% + of our time. We had to build all our UI from the ground up. Half the time it felt like we were reinventing the wheel. Most of our Rich UI came from JQuery combined with Custom HTML Helpers, which were fun to design, but time consuming.

There were other problems we were encountering, like the necessity of DTO-like objects to map from our business objects (fetched from a repository backed by NHibernate) to the Views. And our controllers, which were apparently supposed to be lightweight and easy to maintain, were becoming increasingly cluttered and we were constantly arguing about the proper way to implement controller inheritance.

In retrospect, I feel all the problems we were facing were due to our lack of experience and understanding of MVC. We all liked the idea of MVC, but just didn't have the practical experience and know-how to use it effectively on what I consider to be a very complex (imagine something along the lines of Sales Force, but with better reporting) application.

-- UPDATE --

Been using it the last month to work on a very small project and so far things are going smoothly. It's much easier to work with than the CTP versions I was using a year ago. I am currently looking at my own personal solution for complex "grid views", and then I might switch over completely for most projects. However, Dynamic Data has been treating me proper and I am sort of torn between the 2.