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:
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...
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...
posted by Lizet Pena de Sola at
12:20 PM
0 Comments
