【问题标题】:Is WPF development faster or slower than classic ASP.NET (web forms)WPF 开发比经典 ASP.NET(Web 表单)更快还是更慢
【发布时间】:2011-03-30 18:19:45
【问题描述】:

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

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

例如,这是一个屏幕:

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

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

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

我的问题:

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

换一种方式问:如果一项任务需要(选择一个数字)10 个小时的 ASP.NET 编码,那么使用 WPF 需要多少个小时? 5? 15?

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

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

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

【问题讨论】:

  • WPF 更像是客户端的东西,而 ASP.NET 是服务器端的东西。您正在比较 .NET 的两个完全不同的方面。 (对于它的价值,我已经了解了 ASP.NET WebForms 并且是 WPF 的新手。)
  • 我不知道将苹果与橙子进行比较是否公平。无论如何,我认为这更像是programmers.SE材料。
  • 等等,如果您没有足够的 WPF 经验来提供估算,答案可能是“不,不会更快。”
  • 我不认为这就像你暗示的那样是苹果对橘子。语言、约定和框架是相同的。 Ruby on Rails 和 ASP.NET 都是 Web 框架,但这可能更适合橘子,因为它需要学习新的语言和框架。从 ASP.NET 迁移到 WPF 不需要太多的技能更改。
  • BoltClock:ASP.NET 用于在客户端创建网页。对吗?

标签: asp.net wpf estimation


【解决方案1】:

来自个人经验:

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

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

你不会从我这里得到任何数字,因为根据你给出的输入很难给出它们。

【讨论】:

  • 哦,当然,浏览器疯狂!这应该是我列出的 ASP.NET 痛点的首位。到目前为止,缺乏更好的东西——我将您的“在 WPF 中可能快得多”解释为快 33%。我敢于让你更正那个数字。怎么了,麦克弗利——鸡!?? (原谅我诉诸校园心理学,但我真的需要一个数字。)
  • 我能给你的唯一“正常”数字是 42... 说真的:当你选择一个数字时,你是在自欺欺人。至少在其上添加一个边距以表明您对该数字的确定程度。 (另外:你在这里的行为几乎感觉像是在拖钓)
  • 为巨魔般的语气道歉。没有意识到。试图逗乐,显然错过了。感谢您的回答。
  • @hoyster:不用担心。数字应以真实数据为后盾。只是喊一个数字会严重贬低数字的含义。
【解决方案2】:

变量太多了。选择工具的第一大理由是用户熟悉度。如果您的团队已经了解并熟悉 ASP.NET,那么使用它会好几个数量级并且速度更快。如果您的团队不了解 WPF,那么会有一个加速期,一旦完全加速,他们可能会和使用 ASP.NET 一样快。

但是,如果要求可以安装应用程序,或者需要脱机使用,或者具有仅 WPF 附带的一些其他好处,那么您可能需要接受打击。否则,如果您让团队使用他们熟悉的工具,您将拥有更优质的产品。

如果您试图将您的关注点分开并使用 asp.net 执行 Model View Presenter 样式的方法,我认为这比 WPF 中的 MVVM 需要更长的时间和更多的工作,因为对绑定有很好的支持。但是,仍然有一条学习曲线。

asp.net 或 WPF 没有任何隐含的东西可以让一个比另一个更快。决定发展速度的是团队的人才和他们的适应能力。

【讨论】:

  • “asp.net 或 WPF 没有任何隐含的东西可以让一个比另一个更快”你是根据实际经验说话吗?在我看来,你只是在回避这个问题。
  • 感谢您的回答,NerdFury。我想我没有说清楚,程序员的能力是不变的——一个好的 ASP.NET 编码器和一个好的 WPF 编码器。问题不在于是使用 WPF 还是 ASP.NET。我们将使用 WPF。我对他们的相对生产力感兴趣,您在最后两段中谈到了这一点。谢谢!
  • @Joe white - 我使用 ASP.NET 和 WPF 进行应用程序开发。我没有回避这个问题。我的意思是,如果我采用我的第一个应用程序方法并在按钮单击事件中使用具有逻辑的拖放控件,我可能会在任一框架中都一样快。但是我可以比 xaml 更快地编写 aspx 标记。与在 asp.net 中使用 MVP 模式相比,我可以更容易地将 MVVM 与 WPF 一起使用。这一切都与舒适和乐趣有关。当我玩得开心并使用我喜欢的工具时,我会更快地编写代码。学习新工具也很有趣,但需要付出代价。
  • “没有什么隐含的......” 存在内在差异,IMO。使用 ASP.NET,您需要了解服务器控件、HTML 和 CSS。如果您想要一个不那么平凡的 UI,请使用 Javascript 和图形软件。要避免回发,请添加 Ajax 和 Web 服务。直接的 Javascript、jQuery 或其他库? SOAP 还是 REST? JSON、XML、XSLT?您必须处理状态和缓存,每种方法有 5 种方法。您的解决方案取决于您的硬件:网络农场、会话服务器?事件模型模拟了 VB6,足以让您感到困惑。 WPF:C#、XAML、可靠的事件模型和用于 UI 的 Blend。
  • @hoyster - 你提到的唯一特定于 ASP.NET 的是服务器控件。其余的几乎都是可选的,是 Web 开发与客户端开发主题。不是 ASP.NET 与 WPF。如果您有一个智能客户端,您可能仍然会遇到 Web 服务和肥皂/休息问题。如果您从数据库中获取数据,您仍然需要进行缓存。在根部都有事件模型和可以拖到画布上的控件,然后您对来自控件的事件做出反应。之后您做出的设计决策会影响任一框架之外的复杂性。
【解决方案3】:

我个人认为 WPF 的开发速度比 ASP.Net 快得多,但是如果您正在构建一个估计值,请确保为学习曲线构建大量填充。

到目前为止,我都使用过 WPF,并且更喜欢 WPF。我发现它使用起来更快更容易,与 Winforms 或基于 Web 的任何东西相比,创建我想要的 UI 似乎很容易。

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

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

我看到 WPF 的一个限制是它与 .Net 框架绑定

【讨论】:

    【解决方案4】:

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

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

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

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

    【讨论】:

      猜你喜欢
      • 2012-01-01
      • 1970-01-01
      • 2015-04-07
      • 1970-01-01
      • 2020-11-13
      • 1970-01-01
      • 1970-01-01
      • 2010-11-02
      • 1970-01-01
      相关资源
      最近更新 更多