ASP.Net或WPF（C＃）？
我们的团队是分歧的，我想得到一些第三方的意见。
我们正在构build一个应用程序，不能决定是否要使用.Net WPF桌面应用程序与WCF服务器，或使用jQuery的ASP.Net Web应用程序。 我以为我会在这里问一些问题，看看使用哪一方的优点/缺点。 我有我自己的最爱，觉得我有偏见。
理想情况下，我们希望尽可能快地构build软件的初始版本，然后放慢速度并花费一些时间来构build稍后需要的其他function/组件。 最重要的是我们希望软件速度更快。 用户整天都在进行logging，延迟加载logging或刷新屏幕会降低生产力。
申请细节：
- 我估计大约有100个不同的屏幕用于初始版本，计划在最初的发行版后面增加许多额外的屏幕。
- 我们正在寻找使用双向沟通的提醒和事件系统
- 目前必须支持大约100个用户，尽pipe我们已经被告知允许增长到500个用户
- 我们有多个地点
需要考虑的事项（可能不是在某些情况下，而是在将来的版本中）
- 初始版本之后添加额外组件的空间（有很多这些…可能比初始应用程序在这里工作）
- 键盘导航
- 性能是必须的
- 生产速度到初始版本
- 低维护开销
- 未来的支持
- 软电话/扫描仪集成
我们的开发者：
- 我们有一个程序员在过去的几个月里一直在学习WPF，并build议我们使用WPF。
- 我们有一位熟悉ASP.Net的第二位程序员，他可能会在未来帮助完成这个项目，但是直到最初的发行版本之后，他才会继续使用这个软件。
- 有我，两个谁一起工作，舒适
- 我们有一个外部公司做项目pipe理，他们是一个ASP.Net公司。
- 我们计划雇用1-2个人，但是我们需要知道我们要先走什么方向
环境：
- 一般用户使用terminal服务在Windows 2003服务器上。 他们通过RDP连接使用WYSE瘦客户端进行连接。 pipe理员工有自己的电脑XP或更高。 用户可以指定自己的分辨率，但限于使用IE作为网页浏览器。
- 其他位置通过MPLS连接连接到我们的networking
基于此，你会select什么？为什么？
我特别感兴趣的是有了ASP.Net和WPf经验的开发人员。
selectWPF的理由：
- 比ASP.NET和jQuery更快，更简单的开发
- 更容易实现数据的快速增量后台加载
- 常用数据的客户端caching（对远程办公室很重要）
- 从服务器传输更高效的数据（可以使用Web浏览器无法使用的高级WCFfunction）
- 键盘导航更好，因为您可以轻松定义快捷方式等，而不受浏览器的限制
- 使用MVVM模式更好地维护开销
- 软电话整合容易
selectASP.NET和jQuery的原因：
- 没有，我可以看到
在你的情况下，我一定会selectWPF。
为什么不考虑混合解决scheme – Silverlight
使用Silverlight，您可以获得WPF的大部分优点和状态（具有几乎完全相同的XAML和代码），而且还可以获得ASP.NET的部署特性
许多人认为Silverlight是ASP.NET / AJAX之后的下一个步骤，它肯定会提供与您的场景相关的WPF的所有好处。
首先，我会坐下来写下业务要求和规格。 实际上，无论您使用哪种技术 – 适当的规划都会影响您的项目时间表，而不仅仅是技术select。 对于内部定制应用程序尤其如此。
至于开发，我会采取要求，并布置后端function。 实际上，我将在WCF中实现后端，而不pipe客户端技术如何 – 如果需要的话，您可以使用两全其美的方法（例如对于手机集成，您可以编写一个独立的WPF应用程序）。 使用jQuery的ASP.NET可以轻松地将WCF服务（JSON或XML版本）与桌面客户端一起使用。
就客户的发展而言，这很大程度上取决于开发者的经验和你的未来计划。 我不打算在这里开发networking软件的优势/劣势 – 在过去的十年里，有很多关于基于云/networking的软件（例如salesforce）的文章。 我宁愿把重点放在可交付成果上 – 你们今天和将来最适合的团队是什么？ 从开发angular度来看，WPF和Web开发之间存在巨大差异，并且需要完全不同的体验。
WPF是毫无疑问的路要走。 我同意@Ray Burns所说的。
因为：
- 你会得到一个更丰富，更轻松，更快的应用程序。
- build立1会更容易。
- 软电话/扫描仪（即硬件）集成将要求浏览器插件等，这可能是一个基于浏览器的应用程序的噩梦。
- 原生应用程序的键盘导航仍然更好。
- 使用WPF应用程序，IME维护更容易。
绝对使用WCF通过entity framework提供后端，请参阅分层体系结构中的entity framework 。 您可以在本地应用程序中与后端进行更好的集成，因为它可以内联调用 – 不需要callback或ajax。 我已经构build了WPF组件，通过EF链接到业务逻辑，为简单的东西（如validation）提供可感知的控件。 将客户姓名字段放在表单上，这是非常好的。
要添加额外的组件，您需要用适当的深思熟虑的插件架构来构build它。 这两个环境都是一样的。 我对此有一些想法，我在我的日记中记下了题为应用程序的devise插件体系结构
在构buildWPF应用程序时，您将使用一种语言（例如C＃）+标记（XAML）编写代码。 当你build立asp.net时，你最终会用两种语言+标记，因为你总是需要编写一些Javascript。
所以，根据您的要求，它是WPF / WCF（EF）。 一个基于Web的应用程序将是更多的工作，更复杂，而不是那么好。
大约12个月前，我有幸得到一个自由select技术的新应用程序。 我花了将近一个月的时间来评估所有的选项，并得出结论 ，它必须是C＃，WPF，entity framework。 写完申请后，我可以确认这是正确的select。
1 。 即使你的程序员必须先学习WPF，它仍然会更容易。 WPF好多了，好可爱。 很可爱。 它只是正确的。
你好
我认为The question at issue is Windows-application or Web application （WPF的WIN – 应用VS ASP的Web应用程序）， 哪一个更适合你和你的项目？ 。 在这种情况下，你的平台是networking，你的程序必须在网上工作。 所以对于这个用法Web应用程序是更好的，但有很多点可以做出艰难的决定。 networking平台有很大的挑战（根据我个人的经验）
通过asp.net使用networking应用程序几乎是困难的。 你必须尝试处理许多事情的Web应用程序（请求时间，会话pipe理，甚至比WPF，j-query等糟糕的用户界面）。 记住这不像简单的网站那么简单。
但是，win-app对于这种情况的networking是有好处的：“本地networking”（mpls几乎是一样的）。 绝对开发win-app比web-app（“networking程序开发专家至less”）要容易得多。 对于这种情况WPF有很多好东西（UI，命令等）也有很多挑战（比如multithreading和缺乏这方面的专家开发人员）。 I'm rather with wpf than asp but decisions is yours
和白垩指向Silverlight的好东西，但如果你想使用这个，你必须看看棱镜框架： http : //compositewpf.codeplex.com/
我最近分别用asp和silverlight（棱镜框架）开发了一个项目。 开发银光版本太难了，需要比asp.net版本更多的时间， but at the end SL-ver have great look nothing else!
伯恩斯指出了关于wpf的好问题。 也考虑Artemiy的职位。 他们的环境条件是相同的。 WPF / ASP可以和扫描器和软电话一起工作， cuz the base of both is on C# and .net library
最后，你的决定是你必须聘请高级开发人员，至less开发一个networking平台的商业应用程序。
您的应用是桌面应用还是Web应用
如果桌面wpf是最好的。 如果基于Web的asp.net是最好的。
不要前面加载你的发展与你快速的情况下。 这从来没有效果好，结果在一个马虎的部署。 花点时间，涵盖所有步骤（业务需求，系统devise，程序devise，代码，testing和testing一些，部署）
对于ASP.NET有一些要点：
ASP.NET开发人员的池比WPF开发人员的池大得多。 这意味着您可能更容易find合格的ASP.NET开发人员。
ASP.NET可能是更多的未来certificate，WPF得到大的变化和难以移植到更高版本的机会可能更大。 另外请记住，MS的重点似乎在Silverlight上，所以WPF可能会被淘汰。
ASP.NET更成熟的生态系统使得更多开箱即用的解决scheme可以用来解决问题。
有了多个位置，您可以跳过几个图层直接进入网站？
