Abstract: Should I choose ASP.Net MVC over Web Forms or [closed]

Answer 1

I’ve been using MVC since it was first released. My main reason for wanting to use MVC was due to the fact that SEO/page loading times is an important factor in the web applications I produce and I grew tired of other developers abusing ViewState within our applications despite my frequent explanations as to why 80k of ViewState on the homepage is unacceptable.

I wanted to make use of the Routing Engine for lovely RESTful urls as at that point in time I was using IIS7 for url rewriting on production but didn’t have it available on my dev machine. Using Routing meant I didn’t have to configure the rewrite rules again when deploying to IIS7 since the routes are in code within the application. A Routing Engine is now available in ASP.Net 4.0 Web Forms so you can easily switch from using QueryString parameters.

Note: you ask where you can store temp data such as page index, sort order etc. I commonly tag these onto the URL. This approach works with both Web Forms and MVC e.g.

http://example.com/products/1/asc

http://example.com/products/2/desc

When I first used MVC the immediate thing I noticed is that state management and validation takes more time to implement for user forms with many fields, checkboxes, drop downs etc. This WILL increase your dev time since you have to write custom code to retain state and if you want JavaScript client side validation you need to roll your own also i.e. no required field validators. ViewState is not evil and it is easy to minimise ViewState in a Web Form application. The developer who misuses ViewState is the evil one.

In summary many of the functional requirements you mention e.g. funky GUI features, url rewriting as opposed to query string parameters, calculations etc can be achieved with both MVC and Web Forms and from the end user perspective the website will look the same. The biggest thing that MVC offers is the convention of the design pattern. The reason I forced MVC within my development team is that I wanted the developers in the team to follow the same convention and thus allow us to pick up each others code more easily. What I also love about MVC is that it makes SoC (Separation of Concerns) much easier to achieve. You don't mention TDD (test driven development) in your post, but making TDD easier to achieve is something that MVC also brings to the table.

Answer 2

I am currently working on an ASP.NET MVC web application and have looked at both Java Spring and Rails in my own time and if you are willing to work outside of the Microsoft ecosystem then I highly recommend Rails as the most productive of the three. The hype would tell you that it is 10X faster and from what I have seen that does seem to be a reality and not just hype.

Also from what I have read ASP.NET MVC takes a lot of it's design from rails but without the productivity and ease of use gains.

And yes I realize you have no experience outside the Microsoft ecosystem but rails is very easy to learn compared with ASP.NET MVC and Java Spring/JSF and well worth the effort it will take to learn.

Down vote me I dare you.

Answer 3

I'm afraid MVC might lead to a complex\lengthy system where the flow is lengthy. Will I get lost? Is it scalable if I organize well?

Well, part of that depends on how quickly you pick up the technology.

Overall, ASP.NET MVC is just as scalable as any WebForms solution, and, in my limited experience, probably even more so. You have to remember that MVC is a pattern that is not new - it has been utilized by application developers for years. It is not even really ALL that new to web development, although ASP.NET MVC makes it very easy to do which is one of its appeals.

Some of the traditional advantages of ASP.NET MVC, such as testability for example, go a long way to making the overall project easier to maintain and quicker to build. I built my first ASP.NET MVC website within a week's time, hooking into libraries that had been developed years before, but providing a front-end web-interface. It really was that simple.

The question you asked of: "Will I get lost?" really depends on you and the application you are developing, but only you can answer that. You do have to be willing to put time into learning and understanding MVC...because you are coming from a WebForms background, there will be changes that won't be familiar to you.

Either way, I personally recommend the use of MVC, but, as always, it depends on your project needs.

Update: My own experience with MVC has been extremely positive. I know and understand WebForms just because of using it for the past few years, but I recently started a project at my company and, because I was given the leeway to choose the technologies that I wished to use, I decided it would be interesting to try the MVC model within a web application (the web application is a requirement). My team and I had experience with MVC in desktop applications, but we were all inexperienced with web development in general (as a whole).

The ASP.NET MVC experience was extremely smooth and it was an easy transition for my team to make. I ordered some books for the team, we spent a bit of time coming up to speed in our understanding, and we then began to develop (requirements had already been completed before this step - we were at implementation phase). Like I said previously, it took a week and we had already made great leaps forward - productivity was, and still is, very high. I am very pleased with the MVC model.

You appear to be concerned that the MVC model is going to cause your application to turn into a pile of mush, or to become unwieldy to maintain. As a whole, this is far from the truth. The entire idea of separated concerns makes MVC ideal for scalability of an application, as well as increasing its maintainability and testability. With that said, a lot of how well the application grows depends on your team's understanding of the MVC paradigm and their skills as developers. MVC is not for everybody, nor is it for every project. There are also many other factors to take into consideration with respect to scalability that has nothing to do specifically with MVC (design of the database for example has a HUGE impact - probably more than whatever development paradigm you choose). I personally like ASP.NET MVC, and have had a very good experience with it, but you have to take into consideration all the aspects of your project (team members, time allotted, budget, etc) to make a final decision.