我的问题很简单直接 - DevExpress是否足够快,适用于真实世界的Web应用程序.我们在公司使用DevExpress为客户构建CRM,每个页面都有很多控件,而且速度很慢.在我的开发服务器上,一个页面需要10秒才能加载大约20个控件.这是好事还是坏事?除了案例研究部分给出的应用程序之外,你们能指点我一个真实的DevExpress应用程序吗?
我意识到这个问题很古老,原作者可能早就做出了决定.然而,当我亲自指导我的公司使用DevExpress时,我试图找到所有可能的性能,谷歌搜索总是指向这个线程,许多人喜欢它在互联网上.总是存在一个问题,一些轶事响应,通常是来自DevExpress的人的公关回应.我很少从有经验的人那里找到诚实的答案
在过去,我使用过Telerik,Infragistic和DevExpress.从性能和维护的角度来看,DevExpress是最糟糕的.它们的所有控件都有奇怪的属性和访问器,这些属性与熟悉ASP.NET甚至HTML的人都不一致.由于控件的属性和访问器非常复杂,您会发现在正常的.NET应用程序中,您编写的代码行数是原来的两倍.
DevExpress控件被渲染为非常膨胀的嵌套表.有些控件暴露出更好的轻量级渲染模式,但它们的样式和功能与其他DevExpress控件不匹配,我发现它们在跨浏览器测试中非常错误.
由于控件属性的嵌套和隐藏特性,自定义样式需要许多自定义CSS选择器,这些选择器会强制您将DevExpress类名编码到CSS中.这是非常糟糕的做法,因为DevExpress可以而且应该能够在他们认为合适时更改其内部CSS类名.
这些控件还向其提供资源的DXR.axd处理程序发出了大量的GET请求.
毫无疑问,他们的控制在演示环境中正常工作,只有1显示在屏幕上的控制,但在现实世界中,这些控件是可怕的,应该尽量避免.实现您自己的控件或只下载Bootstrap并使用本机ASP.NET控件.我用我创建的控件替换了DevExpress,这些控件是从.NET渲染的本机HTML类型,下图说明了两者之间资源使用的一些差异.有到页面布局,业务层,数据层,或数据库代码这个交换没有变化,只是更换的DevExpress的控制,我以前想优化,并试图挤的每一点性能的用我自己的控制.
图表将DevExpress与自定义控件进行比较
这很糟糕,但在分配责任时我不会直接指出DevExpress控件 - 我会针对我的代码运行一个分析器来解决问题的真正原因.
它们足够快.DevExpress网站是使用DevExpress控件创建的,从我的角度来看,它运行得足够快.为了能够帮助您提高性能,我们需要知道在慢速页面上使用了哪些控件,同时显示了多少数据,您用于测试的浏览器,以及最终使用的DevExpress控件的版本.
Soham,
作为一般规则,在为网络设计时,请尽量使页面保持亮起,以便它们可以更快地运行.例如,你在一个页面上绝对需要20个控件吗?
如果他们不需要任何特殊功能,那么您可以使用本机渲染.
另外,请查看我在DevExpress web.config设置上的文章,以提高性能.
顺便说一下,我在DevExpress工作.:)