I've been working heavily with WPF (interspersed with WCF and SQL for months at a time) for about the last 3 years. I think everyone who's ever touched WPF or SL has to admit the learning curve is unpleasant and mileage varies depending on background, willingness to drop old methods & what you're trying to achieve.
What we've been developing for most of that time has been a framework app with a lot of modular apps which can be dropped in, all talking WCF for their data. At a glance, we have something like 900 xaml views now and twice that in ViewModels (business logic) and pure model-wrapping data ViewModels. I raise that because I don't think it's all doom and gloom about the development of WPF & productivity is possible once you hit the right patterns & templates. For me, the key is that these days, coding consists of around 98% new features/new pages & only 2% framework code changes. We spent a long period of pain in the 1st year building a UI framework, base classes & style templates in Resource Dictionaries - all for a single modular application. It really was pretty painful at times & we took about 8 routes through finding a mechanism to do Validation, Styling, Binding, Change Detection & a dozen other things.. Each time, we took the plunge and refactored the offending pieces until we got the framework to do most of the grunt work somewhere in a base class. Then we wrote the 2nd modular application for the framework & found more things we hadn't tried to do in the 1st app.. So we added more to the framework.. By the 3rd app we dropped in, it was much, much simpler and quicker to develop. We're now up around 20 applications or so running in it and I think it's paid for itself over the last 12 months. There's a XAML view, there's a ViewModel for the associated business logic, there's models coming down from our WCF service. If the models are just for read-only display, we bind directly to them, if it's something we're likely to edit or update, we create a ViewModel for wrapping the model and exposing events (INotifyPropertyChanged and a couple of our own to notify the Framework of data change & validation results). Early on in our 1st 12-18 months, new devs were coming onto the team and floundering badly because of the weight of XAML & VM complexity that they had to instantly be aware of to be productive. Learning the hard way from this, we went back and added better base classes & some basic clean samples to serve as easy Cut & Paste sources. A few months ago, we had another couple of devs join the project for a month to add some features. Simply due to having simpler, cleaner samples to copy, they finished their new screens in a couple of weeks and generally found it surprisingly easy. In a typical LOB app, 90+% of pages are going to follow the same handful of themes. Textboxes with Labels, Combos, Datagrids, Treeviews (unpleasant control in WPF..:( ). I'd suggest taking the time early on to define some UI snippets which do what you want, so you can come back to them time and again to Cut & Paste your XAML. I've tried Blend, I've occasionally used the VS design surface, but I still find the fastest route by far is to find a sample which does what you want & copy it, then edit the names/binding properties. If you can move all your default styles off into a separate Resource Dictionary, then the XAML comes down to just simple layout & binding, at which point it becomes 1000% easier to copy quickly. For Layout, I'd suggest a Grid 80% of the time with StackPanels within them for when you're less fussy about relative positioning. Add some code snippets to VS for the tedious typing parts of adding columns/row definitions. I wish there was a design tool I could use as quickly, but I seem incapable of using Blend without it sticking all sorts of arbitrary pixel/margin assignments all over the place which mess with my layouts when resized at runtime.. Nice simple XAML (intellisense is a godsend for quick typing entry now) defining the relative layouts is simply quicker and I don't have to go back and edit. There are 3 ways to skin every cat in WPF I think, so find a way which avoids any bugs (I can't recall the last time I had to work around one) and use it everywhere. It might not be the best way, but it'll work & you can copy it for the next 100 pages you write without having to worry about weird semantics. Converters.. Sure, you'll need a lot of converters.. But name them logically, stick them in a common place and after a few months you'll find you don't need to add many anymore because you've covered a lot of your LOB needs & more come only when you start working with the next type of data and you need some weird formatting. Books.. The Unleashed book was the best I found & I've read all 10 or so which were around 18 months ago. Ignore the fancy stuff, it's fun to play with, but frankly you rarely touch it.. Binding, MVVM and understanding basic nuances like why ObservableCollections don't raise an event when a property of one of their children changes, unless that child happens to raise INotifyPropertyChanged, yet adding or deleting one will do.. These will stand you in good stead for a good long while. End result for me is that when I'm writing apps within our framework, I'm much more productive than I ever was writing WinForms, VB or Web Apps (and everything looks much more cohesive because of the common styles everything inherits, which never worked quite right for me with WinForms/VB). However, when I take a step outside our framework to knock up a simple test app or something, I suddenly find myself missing various base class helpers or utility functions we've written along the way and it gets much harder again as I have to hand-crank all sorts of things. I'd struggle to recommend WPF for a small quick project unless you already have Resource Dictionaries of styles to use, but for a longer project, I personally find it a productive medium still.. Although I'm far from immune to the occasional frustration of finding something I expected to be relatively simple, takes me 2 days of head-banging to figure out what Microsoft were thinking when they implemented something (DataGrid and TreeView.... I'm looking at you!).. Martin From: [email protected] [mailto:[email protected]] On Behalf Of Greg Keogh Sent: 25 November 2011 00:47 To: 'ozWPF' Subject: RE: Getting up to speed in wpf Agreed.. books and time.. The biggest fattest elephant in the room is still here ... Productivity! I'm a quite competent WPF and Silverlight developer and I understand what is going on in the background technically (binding, animation, DPs and events, layout, etc), but it still takes me 5 to 20 times longer to write a WPF app because there is no acceptable designer experience like WinForms or VB6. As I said, I hate blend, but is that the cause of my problem? If I take the time and patience to train myself up on Blend, will I be able to use it with the speed and ease that I am used to in WinForms to create complex WPF UIs? Is Blend competency the real answer? There must be people in here who are writing complex WPF layouts and aren't complaining about productivity. If so, what do you actually do when you sit down to write a complex screen layout? I'm sitting here right now this Friday morning creating a WPF primary app screen composed of a dozen child controls all arranged in grid cells with splitters, and I have hand coded the XAML for every frigging control because I know of no other way to do it. I have no styling or animations at the moment, so lord help me when that time comes. Greg Clarity Retail Systems Limited, Paterson House, Hatch Warren Farm, Hatch Warren Lane, Hatch Warren, Basingstoke, Hants, RG22 4RA, UK - Company Registration No: 02739937 - Registered in England The contents of this email are intended for the named addressee(s) only. It contains information which may be confidential and which may also be privileged. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received it in error please notify the sender immediately by return email or by calling +44(0)1256 365150 and ask for the sender. Where the content of this email is personal or otherwise unconnected with Clarity Retail Systems Limited or our clients' business, Clarity Retail Systems Limited accepts no responsibility or liability for such content. It is your responsibility to verify that this email and any attachments are free of viruses, as we can take no responsibility for any computer viruses.
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
