Are you experienced with both ASP.NET and WPF coding? If so, I'll be grateful if you'll share your experience, please.
We are estimating a 100-screen WPF project. Our estimation methodology involves characterizing the complexity of each screen. We then apply a standard number for the development time, based on the complexity and the technology. The standard number is based on the developer being good, not a super-star.
For example, here's a screen:
The user selects a row in the master grid, then edits the data in the detail and saves the changes. Ajax is used to populate and save the detail without a postback. The data layer is already there, and styling will be handled by someone else. The task includes writing an appropriate suite of unit tests; integration testing is separate.
We would characterize this screen as medium and allocate X hours for the task, for classic ASP.NET (as opposed to MVC).
We need help figuring out what X should be for WPF.
My question:
If the screen was being created in WPF, by someone good at WPF -- would it take X hours, or .7 X, or 1.3 X? What is the relative productivity of WPF vs classic ASP.NET?
Asking another way: If a task takes (picking a number) 10 hours of ASP.NET coding, how many hours would it take to do it with WPF? 5? 15?
We'd like to know if WPF is (picking a number) 50% more productive than ASP.NET, so we can propose a lower price and be confident that we will be able to do the project within budget.
[Edit] Asking yet another way: This discussion ASP.Net or WPF (C#)? has a bunch of responses. The selected "correct" answer is "Reasons to choose WPF" and the first reason is "Much faster and easier development than ASP.NET and jQuery".
Is that answer true? How much faster?
From personal experience:
ASP.NET is easier to get into than WPF. ASP.NET quite similar to other web server side technologies. WPF breaks with and adds many features to classic desktop development, that takes time getting used to.
That said, actual development by experienced developers might be a lot faster in WPF. My personal stress factor is browser compatibility (getting it to render exactly the same way in multiple (versions of) browsers; it simply takes too much time.)
You are not going to get any numbers from me as it is much to hard to give them based on the input you have given.
There are too many variables. The number 1 reason to pick a tool is because of user familiarity. If your team already knows and is comfortable with ASP.NET it will be several magnitudes better and faster using that. If your team does not know WPF, then there will be a ramp up period, and once they are fully ramped up, they will probably be just as fast as they were with ASP.NET.
However, if the requirement is that the app can be installed, or is needed offline, or has some other benefit that only comes with WPF, then you probably need to take the hit. If not, you'll have a more quality product if you let the team use the tools they are comfortable with.
If you are trying to keep your concerns separated and doing a Model View Presenter style approach with asp.net, I think that takes longer and is more work than MVVM in WPF, because there is great support for binding. But still, there is a learning curve.
There is nothing implicit to asp.net or WPF that makes one more rapid than the other. What determines the speed of development is the talent of the team and what they are comfortable with.
I personally think WPF is much faster to develop in than ASP.Net, however if you are building an estimate make sure you build in plenty of padding for the learning curve.
I have worked with both and prefer WPF by far. I find it much faster and easier to work with, and creating the UI I want seems so easy compared to anything in Winforms or Web-based.
For example, it is not a problem to do things like create oddly-shaped buttons (starburst, round, etc), create dropdowns w/ checkboxes to filter data, create datagrids which have different UIs for different rows based on the data, popups that make the background semitransparent or blurry, or draggable objects that actually show the object being dragged. These are all things I have played with which are very simple in WPF.
When I first started working with WPF there wasn't a lot of support out there for it, but I believe that has changed. Most problems I encounter have a solution somewhere online, or the answer can be obtained quickly by asking on SO
The one limitation I see with WPF is that it is tied with the .Net framework
I think its safe to say that WPF, in such a project as you describe can be 33% faster, basically because the results are more predictable and controllable. In the end, everyone wants it to look like they want it to look.
WPF is much more naturally reusable and scalable than any ASP.NET project could be. Everything you build can be easily turned into a user control with binding built in. I prefer MVVM to MVC.
I would say you can get something (like a database view) working faster in ASP.NET, but to get it to look like you want will be a lot harder. So your development time really is dependent on how flexible your UI requirements are. If you want to make a new control, it will take a lot longer in ASP.NET and be harder to describe how to use that control to others.
I also started programming recently with VB6 for desktop apps and JQuery with PHP. Development goes a lot faster with these languages than with anything .NET related, because .NET must be compiled. This is a major major drawback to this language. Often it can take quite some time to compile a complicated website. For this reason, for my own personal use, I will stick with jQuery, PHP web services and MySQL.
来源：https://stackoverflow.com/questions/5490456/is-wpf-development-faster-or-slower-than-classic-asp-net-web-forms