Hi Martin,

Thank you for such an in-depth answer.  

It cheers me up immensely!

Kirsten

 

 

  _____  

From: [email protected] [mailto:[email protected]] On
Behalf Of Martin Crimes
Sent: Saturday, 26 November 2011 4:00 AM
To: ozWPF
Subject: RE: Getting up to speed in wpf

 

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.


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6659 (20111125) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf

Reply via email to