WPF 开发比经典 ASP.NET(Web 表单)更快还是更慢

发布于 2024-10-28 08:21:05 字数 926 浏览 1 评论 0原文

您是否有 ASP.NET 和 WPF 编码经验?如果是这样,请分享您的经验,我将不胜感激。

我们正在估计一个 100 个屏幕的 WPF 项目。我们的估算方法涉及描述每个屏幕的复杂性。然后,我们根据复杂性和技术应用开发时间的标准数字。标准数字基于开发人员的优秀,而不是超级明星。

例如,这是一个屏幕:

用户在主数据中选择一行 网格,然后编辑数据 详细信息并保存更改。阿贾克斯是 用于填充和保存详细信息 没有回发。数据层是 已经在那里,样式将是 由别人处理。该任务包括编写一套适当的单元测试;集成测试是分开的。

对于经典 ASP.NET(与 MVC 相对),我们将此屏幕描述为“中”,并为该任务分配“X 小时”。

我们需要帮助来确定 WPF 的 X 应该是什么。

我的问题

如果屏幕是由擅长 WPF 的人在 WPF 中创建的 - 需要 X 小时、0.7 倍还是 1.3 倍? WPF 与经典 ASP.NET 的相对生产力是多少?

换句话说:如果一项任务需要(选择一个数字)10 小时的 ASP.NET 编码,那么使用 WPF 来完成该任务需要多少小时? 5? 15?

我们想知道 WPF(选择一个数字)是否比 ASP.NET 高 50%,这样我们就可以提出更低的价格,并确信我们能够在预算范围内完成该项目。

[编辑]以另一种方式询问:此讨论 ASP.Net 或 WPF (C#)? 有一堆回复。所选的“正确”答案是“选择 WPF 的原因”,第一个原因是“比 ASP.NET 和 jQuery 开发更快、更容易”。

这个答案是真的吗?快多少

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

微暖i 2024-11-04 08:21:05

个人经验来看:

ASP.NET 比 WPF 更容易入门。 ASP.NET 与其他 Web 服务器端技术非常相似。 WPF 打破了传统桌面开发的束缚,并添加了许多功能,这需要时间来适应。

也就是说,有经验的开发人员在 WPF 中的实际开发可能会快得多。我个人的压力因素是浏览器兼容性(让它在多个(版本的)浏览器中以完全相同的方式呈现;这只是需要太多时间。)

你不会从我这里得到任何数字,因为它很难给出它们基于您提供的输入。

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.

泼猴你往哪里跑 2024-11-04 08:21:05

变数太多了。选择工具的首要原因是用户的熟悉程度。如果您的团队已经了解并熟悉 ASP.NET,那么使用它将会更好、更快几个数量级。如果您的团队不了解 WPF,那么将会有一个过渡期,一旦他们完全过渡,他们的速度可能会与使用 ASP.NET 时一样快。

但是,如果要求应用程序可以安装,或者需要离线使用,或者具有 WPF 独有的其他优势,那么您可能需要接受这一打击。如果没有,如果您让团队使用他们熟悉的工具,您将获得更高质量的产品。

如果您试图将您的关注点分开并使用 asp.net 执行模型视图呈现器风格的方法,我认为这比 WPF 中的 MVVM 需要更长的时间并且需要更多的工作,因为对绑定有很大的支持。但仍然有一个学习曲线。

asp.net 或 WPF 中没有任何隐含因素可以使其中一个比另一个更快。决定发展速度的是团队的人才以及他们所擅长的东西。

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.

抚你发端 2024-11-04 08:21:05

我个人认为 WPF 的开发速度比 ASP.Net 快得多,但是,如果您正在进行估算,请确保您为学习曲线做了足够的填充。

我曾使用过两者,并且到目前为止更喜欢 WPF。我发现它使用起来更快、更容易,并且与 Winforms 或基于 Web 的任何内容相比,创建我想要的 UI 似乎非常容易。

例如,创建奇怪形状的按钮(星爆型、圆形等)、创建带复选框的下拉菜单来过滤数据、创建基于数据为不同行提供不同 UI 的数据网格、弹出窗口等操作都不是问题。使背景半透明或模糊,或可拖动对象实际显示正在拖动的对象。这些都是我在 WPF 中使用过的非常简单的东西。

当我第一次开始使用 WPF 时,并没有太多支持,但我相信情况已经改变。我遇到的大多数问题都可以在网上找到解决方案,或者可以通过询问 SO 来快速获得答案。

我发现 WPF 的一个限制是它与 .Net 框架绑定在一起

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

一个人练习一个人 2024-11-04 08:21:05

我认为可以肯定地说,在您所描述的这样的项目中,WPF 的速度可以快 33%,主要是因为结果更可预测和可控。最后,每个人都希望它看起来像他们想要的样子。

WPF 比任何 ASP.NET 项目都更自然地可重用和可扩展。您构建的所有内容都可以轻松地转换为内置绑定的用户控件。与 MVC 相比,我更喜欢 MVVM。

我想说你可以让某些东西(比如数据库视图)在 ASP.NET 中运行得更快,但是要让它看起来像你想要的那样会困难得多。因此,您的开发时间实际上取决于您的 UI 需求的灵活性。如果你想制作一个新的控件,在 ASP.NET 中会花费更长的时间,并且更难向其他人描述如何使用该控件。

我最近还开始使用 VB6 进行桌面应用程序编程,并使用 PHP 进行 JQuery 编程。使用这些语言进行的开发比任何与 .NET 相关的语言都要快得多,因为 .NET 必须进行编译。这是该语言的一个主要缺点。通常,编译一个复杂的网站可能需要相当长的时间。因此,对于我个人的使用,我将坚持使用 jQuery、PHP Web 服务和 MySQL。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文