tags:

views:

118

answers:

6

I know this could be a subjective question, but I want to know your experience and an estimation of how long it would take for a Winforms programmer to switch to WPF and write a simple application.

I'm starting to build a windows application using .Net Winforms. Since the customer cares about the UI, I thought that it's a good idea to switch to WPF at last.
I'm very new to WPF and almost don't know anything about it except some general knowledge.

The application is a single user desktop application with SQL Server Express as the back-end database and will use either Strongly Typed Datasets or subsonic as its DAL. Some basic UI elements (Datagridviews, Textboxes, Buttons, ...) will be used. As you can see it's not a complicated project at all. That's why I was considering using WPF for the first time for this project.

I don't know how long would it take for a Winforms developer to get used to WPF.
Do you think I should start this project using WPF considering its learning curve?
P.S. The project should be ready in about 2 months and I'm a fast learner.

+3  A: 

You can easily and quickly write "WinForms-like" (event handlers, code-behind, etc.) code using WPF and it will work just fine. But it's not really the "WPF way" and will limit your flexibility in the future.

Dan
Thanks Dan. That was informative. But what I really want to know is approximately how long it would take to be able to write proper "WPF style" code.
Kamyar
@Kamyar, Over the last year or so, I spent about 3 months working on various WPF projects (mostly internal tools, but a few weeks for a production sub-system) Only at the end of the most recent project did I feel like I had finally "done it right", so to speak (though I'm sure in a few more months I'll think it was pretty flawed). This came as part of a larger overall shift toward understanding/using unit testing and mocking, which set off a cascade of comprehension that helped clarify the reasoning behind the WPF architecture.
Dan Bryant
+1 for "cascade of comprehension." I also had this happen when WPF finally clicked. I'm a much better programmer now having learned WPF.
bufferz
+2  A: 

I recently created my first more complex (i.e. not enterprise, but not hello world) application in WPF after developing several years Windows.Forms. I would say the switch is not too complicated. You have to learn the new classes and some new styles of coding (e.g. more XAML definitions, different data binding and so on).

Overall I would say that if the application is not too complex you should learn lots of stuff within a week and should be very good at WPF when your project is finished in 2 month.

testalino
+1  A: 

Like Dan said, Use a Canvas and you're pretty close to winforms, but that sucks. EDIT : Before I forget, Don't expect the DataGrid to be anything like the Winforms DataGrid. I tend to use the ListView (with a GridView layout) to replace it in simple cases.

Get a good (i.e. practically oriented) book for a steep learning curve. I recommend Adam Nathan's book, it teaches you the important concepts at a soon-ready-to-go pace.

Sebastian Edelmeier
+2  A: 

a nice comparison about WPF vs Winforms...

http://stackoverflow.com/questions/202079/wpf-versus-winforms

Kishore Kumar
+2  A: 

Many have found this to be a pretty giant leap. Giving an estimation on how long it takes is difficult as it depends on where you're coming from. You might benefit from reading Scott Hanselman's blog posts on his experience when he was learning WPF. It takes you through the development process from beginning to end and the end result (Baby Smash!) is available for download.

steinar
+4  A: 

There are two interesting things (to me) about winforms vs. WPF development.

  • Support for and adoption of the Model, View, View Model (MVVM) approach to development. Though I had used MV* approaches in the past, the concept of databinding, routed events/commands, etc. just seem to lend themselves naturally to an MVVM pattern. From my perspective, this makes coding easier due to separations of concerns.

  • The MVVM approach naturally separates your UI from your data/business logic-- however, WPF goes a step further, and separates your UI from how it actually appears. MSFT has stated that they believe that designers should be designers, and developers should be developers, and that the two skillsets sometimes mix, but pretty rarely. Therefore, they've done a great job with the styling approach within WPF to allow the developers to knock out a quick (ugly) UI, then turn it over to a team of designers who clean it up and make it look pretty-- all without affecting the underlying code. (discussed at MIX '09)

The worst thing I think you could do is try to bring a winforms code-behind approach to WPF development. First, because most of the (recent) materials you will read are oriented toward the MVVM pattern, and second, because you'll find development and maintenance of your applications to be an order of magnitude easier in the MVVM model.

Robaticus