Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm building an LOB app for a very big and serious client, the app itself is not big but my client is so I have to get it right.

I'm generally tempted to always use the latest stuff out there and learn as I go, sometimes this ends up in good productivity. Like when I wrote most of with WCF Data Services over asmx services, and then I used Silverlight over ajax/, these turned out to be a good decisions although there was initial pain in getting off the ground.

Specifically I'm thinking of using WPF over win forms, I've never used WPF, but would the learning curve out-weigh the benefit? Also generally would this kinda thing be a bad move when we're really tight on time?

Second: When it comes to design principals like for example using MVVM in my case. Would that again be an over kill for a small app? (4000 lines as a bad estimate?) Sure my code won't be testable but would I even need such a small app to be testable? Overall I'm trying to keep my base code neat and my UI layer thin.

My question is: Just generally, I want to know, how many serious devs/small companies out there, move to newer technologies or hard core design patterns, practices, frameworks (Prism, CAB) or models (MVVM) for smaller apps? How do make a call for >> complexity + learning curve vs benefit


  1. I'm I have about 1-2 months tops, a lot of base code and almost all planning & design is done.
  2. Its a fixed fee I'm billing which sucks, but they are starting to have a few plans to build more functionality on top.
  3. I (sole dev) will be maintaining it.
  4. Partly I want to choose WPF to provide a better more professional look too, to get them to buy more updates/upgrades on functionality from me.
  5. I actually tried writing my own crazy MVC framework in win forms, it was a mess, I have a "feeling" my code will be better in WPF?
  6. Any thoughts on using MVVM Light?
share|improve this question

closed as primarily opinion-based by durron597, GlenH7, MichaelT, Snowman, gnat Aug 19 at 19:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Well, I'd suggest sitting down with WPF for a day and try and mock up a prototype. It doesn't have to work properly or look perfect, it's just to see how you feel with the tech. Second try and work out how long it will take you to complete the project in WinForms. The difference is the time you have if worse comes to worst and you have to restart. Do consider MVVM because you will at the very least be able to salvage the Model part if you did have to scratch and go back to winforms. So there we go, tl;dr take a day to try it in WPF :) –  Ian Feb 8 '11 at 12:09

3 Answers 3

up vote 3 down vote accepted

Ok, here's some general guidance.

You're writing this for a client, once it is complete, who is going to look after it? If it's the client company, talk to them and develop it in what ever they can maintain.

How long do you have to develop it and are you invoicing them in man days or a fixed fee for the project? It becomes an ethics question then, and my personal choice would be to discuss it with them. If they don't have people who can make that sort of technical decision, just be up front with the benefits or draw backs for each technology, you can pretty much leave out your competence. Which leads nicely onto the next point.

Only you will know if you can get up to speed with WPF in the time available. My suggestion would be to try prototyping it in WPF and if you find yourself drowning in technology, abort and go with winforms.

MVVM is appropriate for small scale projects. You reap a secondary benefit here in that if you decided to switch from WPF to Winforms, MVVM "almost" maps to MVP/MVC. The worst case is you will have neatly separated the business model from the GUI, even if all GUI related aspects need rewriting.

Prism/CAB/SCSF are pretty simple to get started with, there are some excellent getting started guides out there. They get complicated fast. I'm arms deep in one at the moment. You'd be looking at Prism for WPF, SCSF is Winforms (with islands of WPF if necessary). I wouldn't start with it on this project, but again, work through a quick start and see if you think you can fit it in.

With SCSF or Prism, build a working shell, something into which you can plug client content later. It should become a framework you can reuse to reduce the time to delivery. You can either use that time as negotiating space (We can deliver it faster) or as profit space (It will take me 10 days (in reality 2 days because most of the work is done))This way you'll get some familiarity with it, and when a client asks for something it will be a simple case of writing some parts for the framework.

share|improve this answer
+1 great answer. I edited my question with regard to your answer. –  gideon Feb 7 '11 at 16:39
There are great answers here, I'm selecting this one because its the most general answer and covers more than the WPF scenario. Thanks @Ian –  gideon Feb 8 '11 at 14:28

The primary benefit of MVVM is not testability (it's high on the list). What MVVM gives you is simplicity. UI logic is a messy thing. And I would argue that the UI is the most volatile element of any application. Removing the bond between the look and feel of the UI from the logic that drives it will help you maintain your sanity.

That being said, it's almost better not to use MVVM at all than to use it incorrectly (the same can be said of any pattern). It is possible to use WPF without MVVM. But I'd suggest learning as much about it as possible while also (on the side not a money maker) learning how to implement it.

share|improve this answer
+1 thx. Yea I don't know too much, someone recommended MVVM light ??, From the look of the code, all does sound great, but I don't know much about data binding. Would a silverlight book in databinding help? Or maybe I could get a WPF book too? –  gideon Feb 7 '11 at 16:53

I see you mention you want to sell upgrades and updates later on. This means you app will quite likely grow from its currently projected small size. If you foresee long-term maintenance and extension of your small app, you should put some time into making sure it's tested and testable. You'll save yourself a lot of pain later.

As a former WinForms dev, I found WPF to be challenging at first. I'm still not really proficient in it, but I'm not using it every day, so it's hard to say how much of a learning curve there is for someone who's jumping in with both feet. I think WPF is definitely better than WinForms in the sense that it will let you produce a professional-looking app and if you already have an understanding of MVC, MVVM shouldn't be a huge stumbling block. I probably wouldn't worry about frameworks like Prism right off the bat, but I'd read through some tutorials on it to get an idea of how it works so classes can be designed with that in mind, in case I needed to bring it in later (if/when the app grew).

share|improve this answer
yea true, I read up stuff on prism and it does seem an over kill, wanted to actually know how/when others generally use frameworks like that. –  gideon Feb 7 '11 at 17:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.