So it’s way past time that I actually started getting used to a WPF framework, rather than keep re-inventing the wheel. But where to start? I thought it was just between Prism and Caliburn, but then I found WAF, and then researching that I found a whole bunch of others.
I suspect I’ll start with WAF because it describes itself as lightweight. Prism comes from the P&P team, who are normally anything but, and Caliburn supports paradigms other than MVVM, which just seems a bit pointless.
Posts
3 comments:
Having just gone through this I can recommend Caliburn.Micro as it is very lightweight and only really covers MVVM http://caliburnmicro.codeplex.com/
The framework is small, "loosely" documented and incomplete. The net effect is that you can read it all easily, you'll need to read it at some point and it provides good insight into how WPF actually works.
I highly recommend nRoute. nroute.codeplex.com fantastic framework - you can use as little or as much of it as you need.
We're using Prism and whilst I've no problems with it, I have to admit to not really using much of it!
The reason we don't use much of Prism is that our application is not really modular. We have one team, one development stream working towards one release so decided on one module! And as the event broker in Prism is more about x-module (there is no concept of scoping an event to a work-item like cab), we don't use it either! We make a small use of Regions but in hind-sight probably not enough to warrant using Prism!
My understanding is that Prism and Caliburn are not orthagonal. Prism for me is more about modularity and event broker. My limited understanding of Caliburn suggests that MVVM becomes, urm, simpler? :o)
TBH we've hand-rolled most services we need. For example we have a background worker service which will execute a delegate on a background thread, and marshal the result back to the dispatcher. Lines of code == not many.
We have a UI Service which will do things like show a form-view (SL has one but WPF doesn't. We use Paul Stovells Magellan Form / Field stuff for that and lots of Data Annotations for input validation.
And we support MVVM by resolving IBlahView from the container where the concrete BlahView requests it's own ViewModel on its constructor which is wired up as the DataContext. I believe this is the View 1st version of MVVM.
For designer support we have a hand-rolled version of Blends design time data which will insert a datacontext of our choosing at Design Time allowing better visualisation of our views.
Bit of a ramble but hope it helps you make some decisions!
Grae
Post a Comment