Is WPF development faster or slower than classic ASP.NET (web forms)

Are you familiar with ASP.NET and WPF encoding? If yes, I will be grateful if you share your experience, please.

We are evaluating a WPF project with 100 screens. Our assessment methodology characterizes the complexity of each screen. Then we apply a standard number for development time, based on complexity and technology. The standard number is based on the fact that the developer is good, not a superstar.

For example, here is the screen:

The user selects a row in the main network, then edits the data in detail and saves the changes. Ajax - this is used to fill and save parts without postback. The data layer already exists, and the styling will be managed by someone else. The task is to write an appropriate set of unit tests; integration testing is separate.

We will characterize this screen as an environment and allocate X hours for the task, for the classic ASP.NET (unlike MVC).

We need help deciding what X should be for WPF.

My question is:

If the screen was created in WPF by someone good in WPF, would it take X hours or .7 X or 1.3 X? What is the relative performance of WPF and classic ASP.NET?

The request is in another way: if the task takes (number selection) 10 hours of ASP.NET coding, how many hours will it take to do this using WPF? 5? fifteen?

We would like to know whether WPF (number selection) is 50% more productive than ASP.NET, so we can offer a lower price and be sure that we can complete the project on a budget.

[Edit] Ask another way: In this discussion of ASP.Net or WPF (C #)? there are a bunch of answers. The chosen "correct" answer is "Reasons for choosing WPF", and the first reason: "Much faster and easier than ASP.NET and jQuery."

Is this answer correct? How much faster?

+2
wpf estimation
Mar 30 '11 at 18:19
source share
4 answers

From personal experience:

ASP.NET is easier to enter than WPF. ASP.NET is very similar to other server-side technologies. WPF breaks down and adds many features to the development of classic desktop systems, which takes time to get used to.

However, the actual development of experienced developers can be much faster in WPF. My personal stress factor is browser compatibility (getting it to display in exactly the same way in multiple (versions) of browsers, and that takes too much time.)

You are not going to receive any numbers from me, as they are difficult to give based on the input you entered.

+5
Mar 30 '11 at 20:13
source share

Too many variables. Reason # 1 for choosing a tool is that the user is familiar. If your team already knows and is comfortable with ASP.NET, it will be several values ​​better and faster using this. If your team does not know WPF, then there will be a growth period, and once they are fully expanded, they will probably be as fast as with ASP.NET.

However, if the requirement is that the application can be installed or is required offline, or has another advantage that is only available with WPF, then you probably need to take a hit. If not, you will have a better product if you allow the team to use convenient tools.

If you are trying to share your concerns and apply the Model View Presenter style approach with asp.net, I think it will take more time and more work than MVVM in WPF because there is more support for binding. But still there is a learning curve.

In asp.net or WPF, nothing is implied, which makes it faster than the other. What determines the speed of development is the talent of the team and what they are comfortable with.

+2
Mar 30 '11 at 18:27
source share

I personally think that WPF is developing much faster than ASP.Net, however, if you are building an assessment, make sure that you have created many additions to the learning curve.

I worked with both and prefer WPF. I find it much faster and easier to work with, and creating the user interface that I want seems so easy compared to anything in Winforms or web-based.

For example, you don’t need to do such things as create unusual buttons (starburst, round, etc.), create drop-down lists with checkboxes for filtering data, create datagrids that have different user interfaces for different lines based on data, pop-ups, which make the background translucent or blurry, or draggable objects that actually show that the object is being dragged. That's all I played with, which is very simple in WPF.

When I first started working with WPF, there wasn’t much support for it, but I think this has changed. Most of the problems I am facing have a solution somewhere on the Internet, or the answer can be obtained quickly by asking SO

The only limitation that I see in WPF is that it is related to the .Net infrastructure

+1
Mar 31 '11 at 12:48
source share

I think it’s safe to say that WPF in the project you are describing can be 33% faster, mainly because the results are more predictable and controllable. After all, everyone wants them to look like they want them to look.

WPF is much more naturally reusable and scalable than any ASP.NET project. Everything you create can easily be turned into a custom control with built-in binding. I prefer MVVM to MVC.

I would say that you can get something (like a database view) that works faster in ASP.NET, but to make it look the way you want it will be a lot more complicated. Thus, your development time really depends on how flexible your user interface requirements are. If you want to create a new control, it will take much more time in ASP.NET and it will be more difficult to describe how to use this control for others.

I recently started programming with VB6 for desktop applications and jQuery with PHP. Development in these languages ​​is much faster than with something related to .NET, because .NET must be compiled. This is an important major flaw in this language. Often, building a complex website can take quite a while. For this reason, for my personal use, I will stick with jQuery, PHP and MySQL web services.

0
Jun 17 2018-11-11T00:
source share



All Articles