https://stackoverflow.com/questions/21513334
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianI have used both, writing an enterprise level application using CAB and then re-writing it using PRISM (for winforms, not WPF).
PRISM doesn't work for winforms out of the box, you have to hack various things such as region managers, but some of the composite stuff will work (such as Unity or event aggregation). It does take a fair bit of work, (all the PRISM source code is freely available) but there are some dev's who have written blogs about how to get started. Some examples: http://briannoyesblogwp.azurewebsites.net/2008/10/13/composite-extensions-for-windows-forms/ http://blogs.msdn.com/b/gblock/archive/2008/10/20/bringing-prism-to-winforms.aspx
Does CAB work for WPF... why would you want to try to find out? CAB is very old, it is hard to learn because it is so convoluted to do simple things (the learning curve is quite significant) and the memory usage was quite high. One of the goals of CAB was to allow devs to write decoupled software - but there are so many dependencies on framework 'stuff' that it pretty much fails across the board. I understand you are a CAB developer, and being a CAB developer is no small achievement because it takes a lot of time, effort and learning to be able to program an application using CAB successfully (I know, I've been there!), but having moved on to PRISM I wouldn't touch CAB with a barge pole.
When we migrated, we used MVP (MVVM had only just been invented, so we didn't want to go down that path as it was too untested!), and to a large extent it has worked out quite well. Using PRISM for winforms has meant that we lose all the nice data binding that you can get with WPF - but we use a third party tool to handle bindings for us (there are lots of these - telerik is one example, though not the one I actually use).
If you are in the situation where you are able to re-write an application - you will probably find it almost impossible to do a straight port over to PRISM. We had 30 forms in our application at the time of migration, and because of the workload of shoehorning our old CAB stuff into PRISM, we just ended up re-creating it all. In retrospect - we should really have just bitten the bullet and migrated to a WPF implementation of PRISM, as we are now dependent on old outdated tech to fill in the gaps that WPF would have given us for free (like databinding). As already stated, we didn't because both WPF and MVVM were too new and too much of a risk for our stakeholders, but now they are pretty established technologies/patterns - I really think that it is the thing to do, rather than retrofitting your framework (PRISM) to use Winforms.
So - main differences: CAB
- Old, un-supported
- Very steep learning curve, difficult to maintain for that reason (think of needing to get new Dev's to work with it)
WPF
- New, supported and being actively maintained/extended
- Lots and lots of examples out there - it can be difficult to learn - but there are a lot of dev's who are familiar with the tech and so much support available
- WPF specific - you get 2 way binding out of the box, declarative form design (far more powerful than winforms)
- Winforms specific - PRISM promotes a better separation of code from the UI, so your project becomes more testable and less buggy.
If you want information straight from the horses mounth - read this: http://compositewpf.codeplex.com/releases/view/16941 - it's a document comparing CAL to CAB and explains in a lot of detail what done to remedy the shortcomings of CAB.
