On the forums, Bil asked the questions below.
Just wondering about guidance here. I have clients who are not ready or able to move to 3.5/VS2008 yet but need to start developing new Smart Client applications. They're also not ready to move to WPF as they don't see a lot of value in it for the type of apps they need. That sort of leaves me between a rock and hard place IMHO. Prism is good, but only if you're on the 3.5 platform and want to build WPF apps (right?).
Smart Client Software Factory is good if you're on the 3.5 platform and want to build WinForms apps but you're tied to ObjectBuilder and CAB (and we won't open that can of worms). So what does one do when you're living in reality (2.0 platform, WinForms) and need to build new Smart Clients. Are you stuck using either the old SCSF/CAB setup or RYO. Wondering if there's any plans for Prism to be a little more broader than WPF or what the alternaties are?
Below is my answer. I hope this clarifies these questions which are on many customers' minds.
Great question Bil
1. We have an FAQ we will be including in our Docs that clarifies how Prism is postioned against our other offerings. I've posted the content of that below. Let me know if it makes sense. How does Prism compare to patterns & practices’ other Composite UI offerings?
Within patterns & practices, we have several offerings for building composite applications. The following list highlights the scenarios where you should consider using each:
2. As to what to do if your clients need to build composite UI apps, but they are not ready to move to 3.5? In terms of p&p current offerings, SCSF is the only option. Notice I said building composite UI, not smart client as SCSF on the whole is not necessarily appropriate for all smart clients. Once option is to explore using many of the Prism services in Winforms as they are NOT UI dependent (more about this in the next points).
3. On the 2.0 / Winform question, Prism libraries take hard dependencies on 3.5, not only on WPF, but also in LINQ and Lambda usage. Now most of the services do not actually depend on WPF, including Module loading, EventAggregator (currently depends on Dispatcher, but we are moving to use synchronization context). The LINQ/Lambdas could be removed. The RegionManager depends on WPF in it's use of attached properties for registering. But you can also register regions imperatively, thus allowing you to have a WinForm RegionManger that does not use attached properties. Now whether or not the guidance / libraries would be appropriate for Winforms, is a different story and one that you would have to answer.
4. Will Prism be more broader than WPF? Silverlight is definitely something we are looking at. There is already a version for Silverlight on our contrib site. Would do Winforms / Web guidance on Prism? It's possible, though not something we have thought a lot about to date. We've worked really hard to be focused, and not look outside of our main focus area that is WPF. At the same time we the design is very malleable, and loosely coupled, making it potentially usable on other platforms. Mono version of Prism anyone?