Asp.net mvc 4 display modes and controller

I have been playing around with the new ASP.net MVC 4 display mode features where you can add .Mobile to the display page (Index.Mobile.cshtml) and will render the mobile version for mobile. Is it possible to have different controllers for different user agents? Something like HomeController.Mobile.cs? I tried this but it doesn't work. The compiler wants HomeController.cs and HomeController.Mobile.cs to be partial.

I know I can create a Mobile zone and redirect all mobile traffic to that area so that mobile devices have their own controllers. But, I'd rather have something like HomeController.Mobile.cs, so it makes for a cleaner codebase. Otherwise, using ASP.NET 4 Display Modes, the mobile version and the web version of the page will have the same controller logic, which is not always necessary. Any thoughts on how to do this?

+3


source to share


1 answer


The file names don't mean anything to the classes, so I'm not sure what you represent in the idea of ​​"HomeController.Mobile.cs". You cannot have two HomeController classes with the same name as separate controllers / scopes / applications or shared as you noted.

If you agree with the standard convention and have the same controller, you can opt out of your logic based on the device type:

if (HttpContext.GetOverriddenBrowser().IsMobileDevice)
{
    //mobile specific logic
}

      

If you find that many controllers / actions have different logic depending on the type of device, I would say that you have separate applications and it makes sense to use a scope or even a separate network when needed, IMHO. I would try to work out which path I took based on this.



Edit for comments:

I understand what you want; I had to do something similar when I tried to create jQuery Mobile for my blog. Basically, there are three options that I see:

  • Controllers with one set of gates that retrieve all data for all views. Each species just uses what it needs.
  • Controllers with "if (isMobile)" that do some logic and return a mobile view in the case of mobile devices, and do other logic and return the default view in others.
  • A completely separate area or application explicitly for mobile devices (e.g. mobile.yourapp.com).

It sounds like you don't want # 2 or # 3, so what do you consider # 1? The bottleneck in mobile is its resources and network, so I wouldn't be too worried if your server had to do "extra" work to get some dataset that the mobile view never showed.

+6


source







All Articles