您是否熟悉ASP.NET和WPF编码？如果是这样，请您分享您的经验，我将不胜感激。
我们估计一个100个屏幕的WPF项目。我们的估算方法涉及表征每个屏幕的复杂性。然后，我们根据复杂性和技术为开发时间应用标准编号。标准数字基于开发人员 good ，而不是超级明星。
例如，这是一个屏幕：
用户在主服务器中选择一行 网格，然后编辑中的数据 细节并保存更改。 Ajax是 用于填充和保存细节 没有回发。数据层是 已经存在，造型将是 由别人处理。任务包括编写一套适当的单元测试;集成测试是独立的。
我们将此屏幕定义为 medium 并为任务分配 X hours ，用于经典ASP.NET（而不是MVC）。
我们需要帮助确定WPF应该是什么 X 。
我的问题：
如果屏幕是在WPF中创建的，那么在WPF中有人好 - 它需要X小时，或.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更快更容易开发”。
这个答案是真的吗？如何多更快？
答案 0 :(得分：6)
来自个人体验：
ASP.NET比WPF更容易进入。 ASP.NET与其他Web服务器端技术非常相似。 WPF打破并为经典桌面开发添加了许多功能，这需要时间习惯。
也就是说，经验丰富的开发人员的实际开发可能会在WPF中快得多。我个人的压力因素是浏览器兼容性（让它在多个（版本的）浏览器中以完全相同的方式呈现;它只需要花费太多时间。）
你不会从我那里得到任何数字，因为根据你给出的输入很难给出它们。
答案 1 :(得分：2)
变量太多了。选择工具的首要原因是用户熟悉。如果您的团队已经了解并且对ASP.NET感到满意，那么使用它将会更好更快。如果您的团队不了解WPF，那么将会有一个加速期，一旦完全加速，它们可能会像使用ASP.NET一样快。
但是，如果要求是可以安装应用程序，或者需要离线，或者只有WPF附带的其他好处，那么您可能需要接受命中。如果没有，如果你让团队使用他们熟悉的工具，你将获得更高质量的产品。
如果你试图将你的问题分开并用asp.net做一个Model View Presenter风格的方法，我认为这需要比WPF中的MVVM更长，更多的工作，因为有很大的支持绑定。但仍然存在学习曲线。
asp.net或WPF没有任何隐含的东西比另一个更快。决定发展速度的因素是团队的才能以及他们所熟悉的内容。
答案 2 :(得分：1)
我个人认为WPF比ASP.Net要快得多，但是如果你要建立一个估算，请确保为学习曲线建立足够的填充。
到目前为止，我已与两者合作并且更喜欢WPF。我发现它更快更容易使用，与Winforms或基于Web的任何东西相比，创建我想要的UI似乎很容易。
例如，创建奇怪形状的按钮（星爆，圆形等），创建带有复选框的下拉列表来过滤数据，创建基于数据的不同行的不同UI的数据网格不是问题。 ，使背景变为半透明或模糊的弹出窗口，或实际显示被拖动对象的可拖动对象。这些都是我玩过的，在WPF中非常简单。
当我第一次开始使用WPF时，没有太多的支持，但我相信这已经改变了。我遇到的大多数问题都可以在网上找到解决方案，或者通过询问SO来快速获得答案
我在WPF中看到的一个限制是它与.Net框架绑定
答案 3 :(得分：0)
我认为可以肯定地说，WPF，在你描述的这样一个项目中可以快33％，主要是因为结果更可预测和可控。最后，每个人都希望它看起来像是希望它看起来。
WPF比任何ASP.NET项目都更加自然可重用和可扩展。您构建的所有内容都可以轻松转换为内置绑定的用户控件。我更喜欢MVVM到MVC。
我会说你可以在ASP.NET中获得更快的工作（比如数据库视图），但要让它看起来像你想要的那样会更难。因此，您的开发时间实际上取决于您的UI要求的灵活性。如果你想创建一个新控件，那么在ASP.NET中需要更长的时间，并且更难描述如何将该控件用于其他控件。
我最近也开始使用VB6编写桌面应用程序和使用PHP的JQuery编程。使用这些语言比使用.NET相关的任何东西都要快得多，因为必须编译.NET。这是该语言的主要缺点。通常，编译复杂的网站可能需要相当长的时间。出于这个原因，为了我自己的个人用途，我将坚持使用jQuery，PHP Web服务和MySQL。