Portable Areas three years later – Part 5

I have written a lot about Portable Areas in the past and thought it was a good time for an update. The purpose of a Portable Area has not changed.

This is a multi post series on ASP.Net MVC Portable Areas

A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. This could be considered a plug-in or add-in type of functionality.  The portable portion of this approach is that the area can be distributed as a single assembly rather than an assembly and a host of other files, like views or other html assets that need to be managed and maintained over time.  By making a portable area totally self contained in a single assembly, this should allow for easier reuse and upgrades to the area.  The challenge for doing something like this has been how do you allow enough control over the User Interface by the application yet still allow the actual views to be packaged with the logic.

Since the creation of Portable Areas I think the disruptive technologyintroduction of Nuget really changes the implementation of how a Portable Area should be created. A large portion of the challenge that Portable Areas solved was the ability to easy transport, view and assets(Css, javacript) files into an application. Nuget has made this problem go away. So the big sell of a Portable Area is the use of the Message Bus as a way to loosely couple the portable area to the application that is using it. This means the need for the Virtual Path Provider implemented by the MvcContrib project does not need to be used. That is nice because of a couple of reasons. I wrote the virtual path provider and no one has maintained but me. The code is a mess to work with and completely untestable. The use of Virtual Path Providers are discouraged by the ASP.Net team. They can cause performance problems and generally are problematic. I totally agree and I am glad that Nuget allows us to package the views, css, and javascript files into a nuget package as the method for distributing Portable Areas now.

The MessageBus in MvcContrib was good when MVC2 first came out but since then other Mediator packages are available, I would encourage you to use ShortBusas the Mediator implementation and push that over the use of the MvcContrib bus. I think it is better to rely on a package that has a single purpose rather than the one in MvcContrib going forward.



Here is an updated diagram of how a Portable Area works with an application.


Follow me on RSS and Twitter
Follow @ehexter

About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in .Net, Asp.Net, Asp.Net MVC, mvc, mvccontrib, Portable Area. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Guest

    Could you post a more concrete example of the *new* approach?

    • erichexter

      I will certainly do that.

      Eric Hexter

      blog | http://Hex.LosTechies.com
      info | http://www.linkedin.com/in/erichexter

      • Rad

        Did you create a github repository for this? I would really like to have an MVC 4 shell web application and to compose HTML GUI using Portable areas. The problem is how are Portable areas HTML helper known to the shell application at design or run time?


        • erichexter

          They are installed at design time. As nuget packages.

          • Rad

            Yes I know. I would like also to compose Portable Areas at run time (think of a Multi-tenant application) with ability to add new features – as new pages or small widgets to be embedded in another page, layout pages or partial views.

            Will you soon come up with an example of using ShortBus with Nuget based Portable areas deployment preferably using Twitter Bootstrap for MVC?

      • Rgriffith

        Hi Eric, 

        Have you had a chance to post anything regarding this? Excuse me, as I have not implemented nor fully read your original post on the Portal Areas so I do not have all encompasing knowledge of the original work-flow, however as Guest said, a more concrete example would be appreciated. None of what you described above makes sense to me. How does NuGet solve this? I realize I could have a private package feed of my “Portable Areas”, but what does this really replace in the original solution you had posted?

        Thank you so much for your hard work !

        • erichexter

          I have not had a chance to post any additional information on this, but I will do this soon. I like the idea of a private nuget feed. I could see using something like MyGet.com to help organize your own internal portable areas and give you the flexibility to compose your applications.

  • Mykhailo Rybnikov

    I’ve had a task similar to Portable areas functionality. During my investigation it seemed a bit over-complicated.
    Example over using embedded resource approach can be found here: https://github.com/mihasic/MyPlayground

  • I actually did the same thing. Where views, and resources
    (css/js/images) are embedded resources and served directly out of the assembly. Using build
    in support for embedded views from the Spark viewengine pushed me into
    this direction.

    However since then I have iterated into a
    solution where the css/js and images are extracted from the dll and
    placed in a well known location, at application startup. Since
    supporting proper caching from embedded resources was to problematic.

    Your approach seems like a good way to get rid of these custom viewproviders i have been working with all together.

  • NugetHater

    I have a hard time with everyone fawning over Nuget. My experience with it has been one of project configs becoming silently corrupted, constant VS slowness and hangs, and version mismatch hell caused by Nuget itself (versions 1, 2, and 3). My team has lost at least several weeks of productivity to Nuget-related downtime. We uninstalled Nuget from our systems and started using a dedicated Team Foundation Server repository to distribute our third-party library updates, which works without problems.

    So now to see that you’ve posted a vague statement about how Nuget is somehow better than the MvcContrib EmbeddedResource handling approach and then to see in the comments that no one, including you, has posted a follow-up actually showing any concrete within the 6 months since does not give me any confidence you’ve actually tried it in a true-to-life scenario.

    I truly fail to see how Nuget would handle the distribution of js/css/view files in a way that would allow localized overrides, reverting to core versions after overriding, and sane updates of the core distribution without overwriting customizations. From what I’ve seen, it’s just a glorified zipfile extraction framework with a half-baked versioning mechanism.

    Someone please, please give me some counter-examples that show my complaints are unfounded and that will win me back, because I would love to drink the Nuget kool-aid again as long I could be sure it won’t have the same poison in it that I got last time.

  • Nobody Real

    I don’t think Shortbus is a proper solution, as it depends on StructureMap. If you choose to use Ninject or Windsor, there should be no reason to be required to use SM.

    • erichexter

      You could use the common service locator

  • Saeid Mirzaei

    hi all
    How to use Bundling and Minification in Portable Area