我的问题很简单直接 - DevExpress对于真实世界的网络应用来说足够快。我们在公司使用DevExpress为客户构建CRM,每个页面都有很多控件,而且速度很慢。在我的开发服务器上,一个页面需要10秒才能加载大约20个控件。这是好事还是坏事?除了案例研究部分给出的那些,你们能否指出我的真实生活DevExpress应用程序。
答案 0 :(得分:18)
我意识到这个问题已经很老了,原作者可能早就做出了决定。然而,当我亲自指导我的公司使用DevExpress时,我试图找到所有可能的性能,谷歌搜索总是指向这个线程,许多人喜欢它在互联网上。总是存在一个问题,一些轶事响应,通常是来自DevExpress的人的公关回应。我很少从有经验的人那里找到诚实的答案。
过去,我使用过Telerik,Infragistic和DevExpress。从性能和维护的角度来看,DevExpress是最糟糕的。它们的所有控件都有奇怪的属性和访问器,这些属性与熟悉ASP.NET甚至HTML的人都不一致。由于控件的属性和访问器非常复杂,您会发现在正常的.NET应用程序中,您编写的代码行数是原来的两倍。
DevExpress控件被渲染为非常膨胀的嵌套表。有些控件暴露出更好的轻量级渲染模式,但它们的样式和功能与其他DevExpress控件不匹配,我发现它们在跨浏览器测试中非常错误。
由于控件属性的嵌套和隐藏特性,自定义样式需要许多自定义CSS选择器,这些选择器会强制您将DevExpress类名编码到CSS中。这是非常糟糕的做法,因为DevExpress可以而且应该能够在他们认为合适时更改其内部CSS类名。
这些控件还向其提供资源的DXR.axd处理程序发出了大量的GET请求。
毫无疑问,他们的控件在Demo环境中运行良好,屏幕上只显示了1个控件,但在现实世界中,这些控件非常糟糕,应该避免使用。实现您自己的控件或只下载Bootstrap并使用本机ASP.NET控件。我用我创建的控件替换了DevExpress,这些控件是从.NET渲染的本机HTML类型,下图说明了两者之间资源使用的一些差异。此交换的页面布局,业务层,数据层或数据库代码没有任何变化,只是替换了我之前优化过的DevExpress控件,并试图用我自己的控件来压缩每一点性能。 / p>
答案 1 :(得分:7)
这很糟糕,但是在分配责任时我不会直接指出DevExpress控件 - 我会针对我的代码运行一个分析器来解决问题所在。
答案 2 :(得分:6)
他们足够快。 DevExpress网站是使用DevExpress控件创建的,从我的角度来看,它运行得足够快。为了能够帮助您提高性能,我们需要知道在慢速页面上使用了哪些控件,同时显示了多少数据,您用于测试的浏览器,以及最终使用的DevExpress控件的版本。
答案 3 :(得分:5)
Soham,
作为一般规则,在设计网页时,请尽量使网页保持清晰,以便它们可以更快地运行。例如,你在一个页面上绝对需要20个控件吗?
如果他们不需要任何特殊功能,那么您可以使用native rendering。
另外,请查看DevExpress web.config settings to improve performance上的文章。
顺便说一句,我在DevExpress工作。 :)
答案 4 :(得分:2)
我没有DevExpress体验,但您可能还想查看Improving Asp.net performance。它也可能有所帮助。
答案 5 :(得分:1)
2016 - 在过去的5年里,我按顺序使用了Infragistics,Dev Express,Telerik。
Infragistics我甚至没有开始,因为它本身就是一个主题。
我对Dev Express最大的宠儿是他们的控件确实会增加一些"臃肿"总体结果。但是,某些控件确实具有值得臃肿的功能集。当然,他们的Grid和Pivot网格是一个复杂的工具,允许用户做很多事情,我已经成功实现了Devexpress软件包,这些软件包可以很快地运行并获得非常好的结果。 Dev Express有两个问题:
说完这一切之后,到目前为止,Telerik是目前最好的品种。更容易实现,网格快速,具有适当的理想功能,看起来更好。
答案 6 :(得分:0)
如果您使用包含带有窗体布局的文本框的20个控件,则服务器可能会花费很多时间来呈现其中包含很多长标签层次结构的页面。 DevExpress在拥有多个控件方面很糟糕。与ASP.net文本框控件上的数百个字节相比,将一个ASPxTextbox控件重新设置为KB。
答案 7 :(得分:-1)
入口页面有超过20个控件非常常见。我确实使用了devexpress多年,速度和性能都是可以接受的。我们用来构建ERP解决方案。