Clearly one of the options is Prism. Another I heard reference to is Managed Extensibility Framework (MEF). There are additional options out there.
The general question is - how do you deal with particularly large Silverlight application?
Obviously one option is to require your audience to simply hit the page, and when there is a new version or they have cleared their cache - "Progress 1%.... Aren't you in the mood for a cup of coffee right now? Have you said Good Morning to your co-workers today? This might be a while!".
Depending on the audience of your application, this may be entirely acceptable. For many of us here, we're dealing with a typical LOB application that we'd like the ability to fully host and be accessible from most platforms and browsers - a longer initial wait may or may not be even desirable to a larger number of small waits; this may depend on the proportion of the application that a typical user is going to be visiting and how well we can modularize the application.
I remember reading at least once that Rocky has done very little exploration into Prism. That kind of surprises me because it seems that modularization of a Silverlight application is somewhat of a valuable goal being that it's web-oriented and users typically don't expect to wait a long time for content.
So I guess this question is to Rocky and anyone else developing larger Silverlight applications - are you modularizing your application in a manner that lets you do dynamic loads? And if so, what are you using? Home-grown approach, Prism, MEF, etc? Or are you just taking the initial hit when the Silverlight application is initially accessed and getting the whole shabang?
The issue is complicated by any out of browser requirement. If you go OOB you pretty much need everything self-contained in a single xap file, or such is my understanding.
But if you aren't supporting OOB, you just need a way to dynamically load a xap file on-demand. Prism includes that functionality. I don't think ComponentModel.Composition (MEF) does this for you.
This isn't incredibly hard though. For example:
The value of the Composition framework at this point, is that once you've loaded the new assembly/assemblies from the xap you can add them to your catalog and thus get the new types/values to bind into your app dynamically.
Glenn Block demonstrate how to do this using MEF on SilverLight TV http://channel9.msdn.com/shows/SilverlightTV/Silverlight-TV-11-Dynamically-Loading-XAPs-with-MEF/
Prior to .NET 4 you should view MEF as a pseudo-open source project. Many people use it, just like they use other things like Prism, etc. None of which are supported Microsoft products.
In .NET 4 it is now the System.ComponentModel.Composition namespace/assembly, and is part of the .NET framework itself. Today you can use it in the Release Candidate, which has a go-live license. In 5 weeks it will be launched and so somewhere around there will be the RTM of .NET 4 and VS10.
Whether your risk tolerance allows for its use today or not is up to you of course. But given how easy and powerful it is, I suspect Composition will become a common element of many (maybe most) apps.
I haven't directly incorported it into CSLA 4 yet, but I might. At the very least you can bet that I'm making sure you can use it in some key areas - such as dynamic discovery of business rules. And I have some vague concept of its use to dynamically discover ObjectFactory DAL types
Prism and MEF aren't the same thing. MEF provides a (presumably) simpler way to create loosely-coupled designs. Though it's not designed to be an IOC tool, it can perform some of the same functions (and some others that IOC tools can't do.) MEF works on catalogs, and your code exports "parts" that essentially are the pieces that get stuck together using MEF. It's purpose is to provide a general-purpose framework for creating any kind of application/library where you want to provide extensibility points for other developers to plug in their code (think Office/VS add-ins). I believe that MEF is basically a simplified API on top of the System.AddIn namespace.
Prism is a UI framework designed to help you create loosely-coupled, modular WPF/Silverlight applications. It enables its loosely-coupled design via an IOC tool (the default version being Unity). I believe I've seen some postings saying you could use MEF instead, though I'm not sure why you would want to. Prism defines an application architecture with places for you to plug in your business logic, views, etc. by inheriting from base classes/implementing interfaces. But that plugging is done via IOC. As such, it doesn't have the "cataloging" dependency that MEF requires, which IMHO adds another layer of indirection to the whole thing.
I think the confusion arises because lots of MEF examples I've seen talk about injecting user controls into a SL app. A perfectly fine endeavor, and I think MS probably wants to push MEF as the simpler/lighter-weight alternative to Prism (or maybe replace Prism in the SL world completely). But you still have to build the SL shell that MEF sticks its parts into - in Prism, that shell is more pre-defined for you. It's because of this that I think people see MEF and Prism as very similar (or duplicate) technologies.
Scott is right - they are not the same thing, though there's a little overlap in the area of dynamic loading of assemblies and types.
Prism is like all the other PnP stuff - it fills a hole (or set of holes) in the .NET framework, and it is not a supported product. I can't think of any PnP effort that ever became part of .NET, though they've absolutely influenced the direction of subsequent .NET features. One good example is the changes to .NET configuration that came in 2005, which were almost, but not entirely unlike the PnP configuration app block - but you can be there was some examination of the good/bad features of the app block that went into the design of the .NET 2.0 config changes.
I'm not entirely sure where MEF (Composition) came from originally - some skunkworks effort, or maybe out of PnP - I really don't know. But it solves an important and common problem, and (with changes) it has become part of the .NET framework.
The interesting thing about Composition, and why I think it got into .NET where something like Unity didn't, is that it is not hard to learn or use. Contrast this to most of the PnP projects, which have a lot of complexity (conceptual and/or in implementation) and a steep learning curve. They are very pure in terms of pattern implementation, but purity isn't necessarily the goal - developer productivity is the goal. So while the PnP stuff is academically good, and is often very, very useful if you get past the learning curve, it doesn't typically pass muster in terms of the simplicity you'd expect from .NET.
You can spend a couple hours (or less) going through a Composition walkthrough or two, and apply it to your work right away. Low barrier to entry, with reasonable value.
I'm pretty good with reflection and dynamic type loading - the data portal is based on those concepts - but Composition does most of the same things in a simpler and more abstract manner. That's just goodness.
If we're talking about the latter, then is this an alternative to some of the other stuff you're doing along NVVM lines for SL/CSLA version 4?
As I've said numerous times, CSLA is not a UI framework. I don't plan for it to become a UI framework.
Prism is a UI framework. It is one of several open source UI frameworks for Xaml, though I believe it is the only one from Microsoft. For my part I surely don't plan to make CSLA do all the things those frameworks do.
At the same time, I want to be able to sit down with CSLA and be productive, without the need (for a smaller app at least) to incorporate the conceptual and implementation complexity that comes with something like Prism. Prism brings in Unity, which means you have to absorb all the Prism concepts and patterns, and IoC and all its attendant complexity. For a small to mid-size app that's too much for me.
So I at least want the basics - a way to create a form that has no code-behind, a way to display error/warning/information messages, a way to interact with the authorization features of CSLA and a way to interact with the CSLA persistence model.
If you subdivide this, there are some totally optional components you may or may not find useful:
Then there are a couple you'll almost certainly find useful:
ViewModelBase is designed to be UI-framework independent, but to still expose key properties that any UI is almost certainly going to need (Model, Error, CanSave, etc). I can't imagine being very productive building viewmodel objects without the basic concepts provided by ViewModelBase.
PropertyStatus does things that neither WPF nor Silverlight built-in validation concepts handle - error/warning/information severity and multiple broken rules per property. You can certainly live without those concepts, but I find them almost indispensible in my own work.
Yeah, I don't know for sure.
One thing to remember is that dynamic xap loading doesn't mix well with OOB scenarios. I suspect OOB will become increasingly important with SL4 and its capabilities in that regard, so things like MEF and even Prism may have limited utility, at least in that area.
I'm just trying to do what I've done with all the other interface technologies - which is to figure out basic solutions to the rough edges. The ViewModelBase class is an example, where without some plumbing assistance I don't see how it would be practical (or productive anyway) to use any MVVM UI scheme. Especially in SL where all server access is async, so you have to deal with async results and/or errors.
Even if you didn't use your ViewModel<T> as an "actual" viewmodel (as per the other thread) because you think it is too model-centric, the value of the async results/error handling is hard to pass up. It solves the same problems that the data provider model solved, but in an MVVM friendly way
My exploration of the commanding/eventing stuff is as much for my education as anything. Which probably shows in the fact that I have three solutions to the same problem (InvokeMethod, Execute and TriggerAction). Though I don't take full blame for that, because Microsoft keeps changing the way they support these ideas too (Execute came from the Blend 3 stuff, which isn't in VS10, and TriggerAction comes from VS10, and imo really is the best answer thus far).
In the end it is as I said though - I want to enable people to use any UI framework they think is cool. But I also want to enable raw use of CSLA, at least to create a basic LOB app.
Though what I'm running into with that last requirement is that MVVM is not really a practical answer without at least a basic abstraction of a rendering component - which is where that Bxf idea I've been working on comes into play. Thus far I've resisted the temptation to roll it into CSLA - which is for the best given how fast it has been evolving.
But at the end of the day, you must acquire or create some UI framework or you really can't play. Even a basic app with a small number of screens, assuming you want testability, no code-behind and maintainability, requires at least a small bit of UI framework goo - again to abstract rendering and messaging if nothing else.
Copyright (c) Marimer LLC