Things I cannot do in ASP.NET MVC

Question

Are there some things I cannot do with ASP.NET MVC? Things that are only possible with ASP.NET WebForms, or extremely much easier with WebForms?

We consider u

Answer 1

ASP.NET Ajax is not working with ASP.NET MVC so no UpdatePanel (due to lack of postback). Fortunately there is built-in ajax (Ajax.Form) which can be used to perform partial updates not to mention jQuery which is shipped by default with the Visual Studio project template.

Answer 2

The big one is Controls. User Controls are not available with ASP.NET MVC. I have even gone so far as to try using code like this:

new Label().RenderControl(...ResponseStream...);

No dice.

Of course, as a part of that, there is no need for view state, so that isn't in there.

Server controls do work, though.

Answer 3

The biggest one would be using existing 3rd party controls on your form. Most of the inbuilt controls are pretty easy to reproduce, but if you have a pet 3rd party control, you might have to host that on a regular (non-MVC) aspx page (luckliy this is supported).

Likewise, "web parts"

Also - the feature where ASP.NET uses different html for different clients (mobile, etc) becomes... different; you wouldn't want to do this by hand, but in reality most clients now work with standard html, so it is less of an issue in the first place.

Some things like i18n via resx files need extra work than is in the vanilla MVC template, but the samples are there on the internet.

One point... MVC is licensed only for MS/ASP.NET; so one thing you can't do (without violating the terms, as I understand it) is to run it in mono/Apache - but IANAL.

Now consider the things you can do with MVC, that you can't (or are hard) with vanilla:

• routes instead of pages
• automated input resolution (action arguments)
• proper html control...
• ...enabling jQuery etc for simple AJAX
• separation of concerns
• testability
• IoC/DI
• multiple templating options (not just aspx/ascx)

---

re input resolution:

public ActionResult Show(string name, int? page, int? pageSize) {...}

will pick "name", "page" and "pageSize" off (any of) the route, query-string or form - so you don't have to spend lots of time picking out request values.

re templates - aspx/ascx aren't the only templating options. For example, see here; or you can write your own if you like... The view is not tied to ASP.NET controls at all.

Answer 4

I think view-state is non existent in MVC. You will have to track your own view state in some other way than the built in view-state in non MVC projects.

EDIT: According to comments: "Getting rid of ViewState is an advantage not a disadvantage". – Craig

Answer 5

As Marc said, third party tools and (serverside) webcontrols cannot be used. So slapping something together quickly by dragging and dropping a few controls on a form (like a grid and a dataaccess control) is no longer an option.

But with the codegeneration etc. you can still make something quickly. And you still have the above option if you need something quick.

Answer 6

Validation is not as easy as in WebForms. In Webforms you can add a validator and just set a property that enables clientside validation. You can localize the errormessage. The localization works clientside and serverside.

There is no out of the box clientside validation in MVC and you need to find a way to localize clientside errormessages.

Localization itself is different. Ressources obviously by default dont exist per page, because there is no page. But there is a good way to have ressources per view.

I still did not check, if it is possible to set SSL-required per folder.

EDIT

The story is different with MVC3. There is a good validation support now.

There are still things that are not implemented in MVC. The biggest issue for me is a complete implementation for donut cashing and partial cashing. There is some improvement in MVC3 in this area but it is still not complete. Anyway stay tuned: the MVC team seams to be aware that this is something they should work on.