ASP.Net或WPF(C#)？

Question

ASP.Net或WPF(C#)？

我们的团队对此有所分歧,我希望得到一些第三方意见.

我们正在构建一个应用程序,无法决定是否要将.Net WPF桌面应用程序与WCF服务器或使用jQuery的ASP.Net Web应用程序一起使用.我想我会在这里提出一些问题,并提出一些规格,看看使用任何一方的利弊是什么.我有自己的最爱,觉得我有偏见.

理想情况下,我们希望尽可能快地构建软件的初始版本,然后放慢速度并花时间构建我们以后想要的其他功能/组件.最重要的是我们希望软件快速.用户整天都会查看记录,加载记录或刷新屏幕的延迟会影响他们的工作效率.

申请细节:

我估计初始版本大约有100个不同的屏幕,并且计划在最初版本之后添加许多额外的屏幕.
我们希望使用双向通信来提醒和事件系统
目前必须支持大约100个用户,尽管我们已被告知允许增加多达500个用户
我们有多个地点

要考虑的项目(可能最初在某些情况下,但在将来的版本中):

初始发布后要添加其他组件的空间(这里有很多......可能比初始应用程序更有效)
键盘导航
表现是必须的
生产速度到初始版本
维护开销低
未来的支持
Softphone/Scanner集成

我们的开发人员:

我们有一位程序员在过去的几个月里一直在学习WPF,并建议我们使用WPF.
我们有一个熟悉ASP.Net的第二个程序员,他可能会在将来对该项目有所帮助,尽管他不会在最初版本发布之前对其进行大量工作,因为他的时间用于维护我们当前的软件.
有我,两个人一起工作,也很舒服
我们有一家外部公司负责项目管理,他们是一家ASP.Net公司.
我们计划招聘1-2人,但我们需要先了解我们的目标

环境:

一般用户在具有终端服务的Windows 2003服务器上.它们通过RDP连接使用WYSE瘦客户端进行连接.管理员工作人员拥有自己的XP或更高版本的PC.虽然用户仅限于使用IE作为Web浏览器,但允许用户指定自己的分辨率.
其他位置通过MPLS连接连接到我们的网络

基于此,你会选择什么,为什么？

我特别感兴趣的是那些有ASP.Net和WPf经验的开发人员.

Answer 1

Ray*_*rns 39

选择WPF的原因:

比ASP.NET和jQuery更快更容易开发
更容易实现快速增量后台加载数据
更容易实现常用数据的客户端缓存(对远程办公室很重要)
从服务器传输更高效的数据(可以使用Web浏览器无法使用的高级WCF功能)
键盘导航更好,因为您可以轻松定义快捷键等,而不受浏览器的限制
维护开销太大更好的使用MVVM模式
软电话集成容易

选择ASP.NET和jQuery的原因:

没有我能看到的

在你的场景中,我肯定会选择WPF.

"选择WPF的原因:•比ASP.NET和jQuery更快更容易开发"你必须使用不同版本的wpf而不是我.拿一些基本作为输入验证的东西,其中一个字段依赖于另一个字段,看看它在wpf中实现的难度 (7认同)
我经常做那种输入验证.你觉得它有什么困难吗？更重要的是:您使用WPF与ASP.NET有多长时间,并且您是否正在使用MVVM进行WPF开发？WPF只需要少得多的代码和更少的调试,因此开发速度更快,更容易. (2认同)
EF + MVC还具有自动验证功能.无论如何,我在网络环境中开发它会更容易,因为我知道它,而且我不知道WPF.所以#1点是有争议的. (2认同)
你错了.在Windows上,我个人在IE,Firefox,Chrome和Safari中使用WPF.Silverlight带来的是跨平台功能 - 能够在Mac,Linux,WinPho7等上运行.权衡的是,Silverlight仍然缺少WPF的一些最佳功能,例如MarkupExtension. (2认同)

Answer 2

Dea*_*alk 9

为什么不考虑混合解决方案 - Silverlight

使用Silverlight,您可以获得WPF的大部分优点和状态(几乎完全相同的XAML和代码),还可以获得ASP.NET的部署特性

许多人认为Silverlight是ASP.NET/AJAX之后的下一步,它肯定会提供与您的场景相关的WPF的所有好处.

@Rachel:使用WPF建立类似的业务线应用程序仅一年多,然后花费过去两个月构建一个Silverlight业务线应用程序,我同意对于给定的场景WPF是一个更好的选择你说的原因是为了Silverlight. (2认同)
@Lex:您的评论显示您对WPF的理解存在一些差距:1.WPF支持Web部署,这与最终用户的Silverlight无法区分,2.WPF比Silverlight更好地进行多层,3.WPF有更多的控件, 5. WPF有更多的XAML功能,6.WPF有更多,7.WPF有P/Invoke,*full*COM interop,HwndSource等,因此Softphone/Scanner互操作可能会容易得多(同时COM-interop消除了Silverlight的一个优势) ).底线:Silverlight很棒,但除了多平台能力之外,WPF仍然在各个类别中获胜. (2认同)
@Lex:1)XBAP适用于IE,Firefox,Chrome.显然WPF具有浏览器外功能(!).是的,如果正确设置,OOB过渡可以与Silverlight完全相同.2和6)一个这样的例子是我自己的EDF框架,由于Silverlight缺乏高级绑定,它的DependencyObject限制以及通信限制,因此需要一堆丑陋的工具来使用Silverlight.Silverlight非常棒**,但只要你不需要跨平台,WPF就会更好**. (2认同)

Answer 3

Art*_*miy 8

首先,我会坐下来写下业务要求和规范.使用什么技术并不重要 - 正确的计划会影响您的项目时间表而不是技术选择.对于内部定制应用程序尤其如此.

就开发而言,我会采用这些要求并布置后端功能.我实际上会在WCF中实现后端,无论客户端技术如何 - 如果需要,你可以使用两种方式中的最佳方式(例如,对于手机集成,你可以编写一个独立的WPF应用程序).使用jQuery的ASP.NET可以轻松地将WCF服务(JSON或XML版本)与桌面客户端一起使用.

就客户端表单的开发而言,这在很大程度上取决于开发人员的经验和您未来的计划.我不打算在这里开发网络软件的优点/缺点 - 在过去10年中有大量关于基于云/网络的软件(例如salesforce)的文章.我宁愿专注于可交付成果 - 您的团队在今天和未来最舒服的是什么.从开发的角度来看,WPF和Web开发之间存在巨大差异,它需要完全不同的体验.

Answer 4

Ric*_*son 5

毫无疑问,WPF是可行的方式.我同意@Ray Burns所说的一切.

因为:

您将获得更丰富,更光滑,更快速的应用程序.
构建¹会更容易.
软件电话/扫描仪(即硬件)集成将需要浏览器插件等,这可能是基于浏览器的应用程序的噩梦.
使用本机应用程序时键盘导航仍然更好.
使用WPF应用程序可以更轻松地进行IME维护

绝对使用WCF通过实体框架提供后端,请参阅分层体系结构中的实体框架.您可以在本机应用程序中与后端进行更好的集成,因为它可以被内联调用 - 不需要回调或ajax.我已经为WPF构建了组件,这些组件通过EF链接到业务逻辑,为验证等简单的东西提供感知控件.将客户名称字段放到表单上是非常好的,它只是起作用.

要添加其他组件,您需要使用经过深思熟虑的插件架构来构建它.这两种环境都是一样的.我对此有一些想法,我在我的期刊" 应用程序的设计插件架构 "中记下了这一点

构建WPF应用程序时,您将使用一种语言(例如C#)+标记(XAML)编写.在构建asp.net时,您最终会使用两种语言+标记,因为您始终需要编写一些Javascript代码.

因此,根据您的要求,它必须是WPF/WCF(EF).基于Web的应用程序将是更多的工作,更复杂,而不是很好.

大约12个月前,我很幸运能够自由地为新应用选择技术.我花了将近一个月的时间来评估所有选项,并得出结论,它必须是C#,WPF,实体框架.编写应用程序后,我可以确认这是正确的选择......

¹.即使你的程序员必须先学习WPF,它仍然会更容易.WPF更好的思考,伟大而可爱.很可爱.它运作正常.

归档时间：	14 年，11 月前
查看次数：	36215 次
最近记录：	11 年，3 月前