Archive for April, 2009
I’ve just uploaded the material (slide decks and source code). It can be downloaded here.
I think the presentations went pretty well, and got some great feedback from it. It was great seeing some old buddies there, and meeting new ones.
One interesting thing: when I first read Robert C. Martin’s book, “Agile Principle, Patterns, and Practices in C#”, I thought of creating some sort of book club, having developers study and discuss each chapter of the book. Due to my lack of time, I never executed the plan. Talking with Zack last night, he mentioned he started doing that as a virtual club on LiveMeeting. I definitely want to see whether I can join them.
Also, we’ve discussed the idea of having “brown bag lunches” over LiveMeeting. I’m seriously interested in getting involved on that one.
Here’s a few questions I got from my session on the “Composite Application Guidance for WPF and Silverlight” (aka. Prism) for the MS TechDays, along with my thoughts on it:
What issues have you run into resistance-wise with people moving from WinForms to WPF, and then taking the leap to a composite UI framework such as Prism? I’m seeing pushback due to training, retooling, and general "fear of the unknown."
Going from WinForms to WPF isn’t easy. Sometimes it seems like going from DOS to Windows. In a way, it may be easier for a developer to go from WebForms to WPF, since XAML looks kind of similar to HTML, or since web developers are used to laying out controls using HTML tables (whereas in WPF one can use “grids” as layout controls).
There are lots of things to learn in WPF, including XAML, dependency properties, attached properties, data binding, styles, templates, animation, visual and logical trees, etc. The current tools (Visual Studio 2008 and Expression Blend 2) aren’t solid yet; fortunately, both Expression Blend 3 and Visual Studio 2010 look promising, coming up with fixes and new features that address many of the current pain points.
With that said, WinForms isn’t going anywhere. The .NET Framework didn’t add anything new to it after version 2.0. All the big improvements regarding framework and tooling are aimed at WPF. Anybody in need of creating Windows applications today should probably consider WPF. Learning WPF has the extra advantage of reusing good part of that knowledge and skill when creating Silverlight applications, which is likely to be a big thing in the years to come.
In regards to taking the leap to a composite UI framework such as Prism, I don’t think it matters whether the developer is working with WinForms or WPF: either way there’s a learning curve there, given the fact that most developers aren’t used to creating composite applications. Most developers are used to creating forms that show all of its elements when open in the Visual Studio IDE. When building a composite application, the developer won’t really see what it looks like until the application is run. So that’s a first hurdle: getting used to the fact that during design time we only get to see the individual pieces (usually “user controls”) of a jigsaw puzzle (the actual application).
Another aspect that comes into play is that composite applications should really be built with separated presentation patterns in mind (Model-View-Presenter, Model-View-Controller, Model-View-ViewModel, etc.). The reason for that is to keep a clear separation between the UI and the other parts of the application. This is another thing that most developers aren’t used to; they’re used to open up a form in the IDE, drop a button onto the form, double-click the button so to add an event handler, and stuff a bunch of code in that event handler (retrieve data, update other UI controls, validate data, etc.). Driving a developer away from that way of building applications doesn’t happen overnight.
I haven’t really used the previous efforts coming from Microsoft regarding the creation of composite application (such as the “Composite Application Block”), but what I’ve heard from other developers who have is that they were really hard to understand, and were way too coupled to the other application blocks (data, configuration, dependency injection, etc.). Fortunately, Microsoft understood that feedback and addressed those issues with Prism, whose Composite Application Library can be considered very small (just a few core pieces to learn) and very loosely coupled (one can use whichever frameworks they want for UI controls, data access, dependency injection, etc.).
So, going back to your list of pushbacks:
- Training: yes, WPF is a new thing, and therefore developers have some learning to do.
- Retooling: the main tool for developers in WPF is still Visual Studio, so there isn’t much difference there, other than learning things that are specific to WPF (such as how to hook up data binding, and things like that). However, in order to create visual appealing applications, the developer should also learn how to use Expression Blend, unless the company has professional designers working on the project who are doing all the visuals of the application.
- “Fear of the unknown”: WPF can’t really be considered an unknown at this point anymore; it’s been released about 2 and a half years ago, and it is definitely where Microsoft is going with UI development. Regarding the architecture and practices followed by Prism (composite application, separated presentation patterns, loosely coupled modules, etc.), those aren’t unknown because they’re new (they’ve been around for a long time now); they’re unknown because both companies and developers, unfortunately, choose the quick-and-dirty-big-pile-of-spaghetti-code route when writing applications.
Where have you seen Prism (or WPF) hinder overall application performance or introduce sluggishness? Because of dependency properties and an event manager, there’s quite a bit running "behind the scenes." Have you identified anything specific?
I haven’t really noticed anything there. Prism does add some overhead, since it needs a couple extra objects to be able to do the UI composition; however, that doesn’t seem to be noticeable. WPF itself should perform better than WinForms in some cases because it offloads UI rendering to the graphics card (provided a good card is available), freeing the CPU to do more important stuff (such as running business logic).
I was concerned at first that you picked the stock trader app to demo, as that can be a bit overwhelming to someone new to Prism (but nowhere near as overwhelming as the SCSF reference apps!). I really like how you toned it down though, and focused on some very targeted and isolated areas of code, without trying to explain how the entire app comes together.
That’s great feedback. Thank you. I was worried that maybe I should have showed more code, but for the time I had available for the session, it seemed better to me to concentrate on the core concepts of Prism, show a little bit of what the code looks like around those concepts, and what kind of thing can be found in the reference implementation. Hopefully that gave people enough information to go ahead and inspect the reference application on their own now.
How did you do the polls? Was that part of LiveMeeting? I’ve gotta figure that out and try it in an upcoming webcast!
Yup, that’s a feature of LiveMeeting, extremely simple to setup: in “contents”, you just pick “add poll” (or something like that). Then you add your question, the available options, and you’re all set. 🙂
I hope I’ve been able to clarify some of those points. Please let me know of your own experiences using Prism.