MVC4 - DisplayMode versus Areas for creating a client portal to internal business app

Question

I have an MVC app intended for internal company use (but designed with the knowledge that eventually we'd be providing clients access) that is currently served over the internet (ssl). We're now looking at providing clients access to it, and their their accounts. Profile editing, program enrollments, status of current services, pretty typical stuff. But I'm see-sawing on how to go about it. There are bound to be things that are unique to the public access that doesn't apply to company employees but I'd like to keep this as DRY as possible and still try to keep the existing code streamlined. I've come up with two options and I'm looking for opinions and insights I may be missing. Am I committing any design faux pas entertaining this or am I missing another option?

---

MVC4 DisplayModes

MVC4 offers the ability (via DisplayModes) to serve alternate Views based off custom criteria. The default implementation is based off of the AgentString and is used to serve alternate views for mobile devices (tablets, phones). But I've tested it and it can also be used to serve up alternate views based off of other criteria, like user information (being in a certain role). I'm thinking I could add a role to the system that is unique to public client accounts that would result in them getting alternate views if the customizations are major and if not, to let it fall back to using the default view if the customizations did not necessitate a brand new view. The rest of their access would be handled as much as possible using existing permissions, roles, and security restrictions. The downfall as I see it is that the Controller Actions would be the same for both employees and public clients, so it may get a little muddy with different code paths depending on if the user is an employee or a public client. Not to mention the possability of unintentionally exposing something that is meant for employees only. But it would also keep the views very DRY.

global.asax

var displayModes = DisplayModeProvider.Instance.Modes;
displayModes.Insert(0, new DefaultDisplayMode("Client")
    {
        ContextCondition = (context => context.User.Identity.IsAuthenticated && context.User.IsInRole("Client"))
    });

---

MVC Areas

MVC also offers the ability to use Areas as a way to offer a sort of separation of parts of an application within the same site. So I could create an area called Portal for example to serve as a client portal to the website/application. using this method I should be able to inherit from the Controllers used for the primary portion of the site and either override certain actions as needed when it needs different logic for the client portal and let the rest fall through to the base class (I haven't tested this theory yet but I'm assuming it would work?). I think this would result in DRY controllers but not so much for the views as I'd have to copy any views I need from the main site even if they don't need any changes. The below code is a bit contrived but it gets the point across I think.

namespace MyCompany.Web.Areas.Portal

public class ClientInvoicesController : MyCompany.Web.InvoicesController
{
    public new ActionResult List()
    {
        var clientId = invoiceService.GetCurrentCLientId();
        var invoices = invoiceService.GetInvoices(clientId);
        return View(invoices.Where(x=>x.HideFromClient != true).ToList());
    } 
}

---

Has anyone else looked at something similar to this? I don't want to get too far down one path or the other until I get a second opinion on my thought process so any help you could offer would be appreciated.

Answer 1

Do you think in the posibility of use the Areas approach (I think its the better for your proyect) combined with partial views for the views that are the same for both areas?

This allow you to decouple both parts of the application, but you can re-use the views and take advantage of the inheritance of controllers.