Category: web composition pluggable architecture

Composing web applications with the ASP.NET frameworks in the market… MVC 2 Areas vs MVC with MEF

On my previous post I ranted about the need my team has for a plug in implementation for a web portal. I’m sure this requirement is on almost every web team that develops a web portal.

We were paying close attention to the ASP.NET MVC framework in conjunction with MEF:

MEF and ASP.NET MVC sample

and see great potential here. the only drawback is that plug ins will run as part of the same application domain, afaik. This might not be a drawback if your plug ins do not need to be hosted on a different service and domain.

We took a close look at the Areas in ASP.NET MVC 2 Preview 1 recently released, but the concept of Areas is mostly for organizing big web projects, not for developing modules as plug ins.

See the copy and paste from this blog post by Haacked:

… right now, Areas isn’t intended to address the “pluginnable” architecture. We started going down that route but it raises a lot of challenging questions such as where does the database go and how do you handle communication via areas and how do you administrate plugins?

I’m not sure that the core framework at this time is the place to put these concerns. I see this as something that might be better left to a higher level framework on top of ours, much in the way that DotNetNuke or Drupal are hosts for plugins.

However, I’m not closing the door on this, but I think you’ll see we’ll take a very iterative incremental approach. Right now, Areas is focused on helping teams manage the complexity of an application. It’s a small step. We’ll be looking at application composition as we move forward.

@Peter, For the security boundary question, at the end, it’s still just one application. Everything is merged into the same app running in the same AppDomain. So they share the same security boundary in that regard. Of course, you can use AuthorizeAttribute and other means to create security boundaries around areas should you choose.

I’m not sure my team would like to go for DotNetNuke unless it is rewritten on MVC, this is only my personal opinion and I would have to POC further before reaching a conclusion.

MEF so far looks like a good candidate…

WCSF falling short on composing web applications?

I’m right now looking for options on composing web applications. I recently took part of an interesting project with the composite application block framework (CAB) developed by the patterns and practices team and am certainly looking for the web equivalent. That been said I should add I have a great deal of frustration now.

I had been subscribed to several discussion threads at Codeplex for the web composite application block and WCSF. At the moment of writing this post codeplex.com is down (it has been down for about 2 hours now at 4.18 PM EST) and southworks.net is down too.

SouthWorks.net is the company that has more developers maintaining these application blocks, afaik, and they also moderate most of the codeplex threads.

After reading about the road map of the Composite Web Applications I tried out the QuickStarts for the WCSF hoping to find the web equivalent of CAB or Prism.

My team has a couple of “legacy” web asp.net applications that were migrated to asp.net 2.0 two years ago.

We were looking for a framework that would serve as a skeleton for composing web solutions.

IoC containers such as Spring.NET allow composability at object level, but it’s cumbersome to have all the objects that you’ll inject into your main application defined in a main configuration file. *this is as far as what i’ve seen* And we wanted to be able to use existing applications with a minimum of re-write (maybe some style changes).

That’s why modules might be a better choice of dividing and composing applications. Each module could have it’s own set of configurable objects, it’s own configuration file and it’s own UI and would communicate with other modules through an event broker mechanism and would consume information presented by the services registered or published by the shell…

WSCF appeared to be the answer, until after we tried the QuickStarts.

The modules do not have a UI at all, the UI is defined in the main web application (web project) where the web.config file resides. The modules are merely a group of business objects and presenters. I don’t think the modules are loosely coupled at all, as the view is defined in the main application (web project) and the name of the view or web form is also declared in the sub module.

I might be very biased by the architectural design of Facebook, but composability in that case means, you can host *any* application on your main *shell* and this application will consume services to communicate with the main shell, using encryption with a key provided at the time the application is registered.

…they surely share session…

Why WSCF falls so short on this?

My real world problem: I would like to integrate the existing web applications into a new shell with minimum changes. These legacy applications are now on different virtual directory and run on different appdomains. They do share a single sign on implemented as shown here:
http://forums.asp.net/p/1023838/1390821.aspx
but there is no shared session.

These web applications although might be considered legacy, are fully functional and have been tested. Rewriting them would cause more pain that help the business.

It seems that if the team goes for WCSF we will have to end up rewriting these application into WCSF modules and moving all the webforms and user controls to the web project as oppose to do small modifications to integrate them into a true composable shell. This would be extremely painful.

I’m still looking and to be honest, I’m kind of lost, it must be it is Friday afternoon. Any comments or suggestions would be more than welcome…

Thanks!