asp.net - DevExpress for ASP.NET 是否足够快

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

去年关闭。




Improve this question




我的问题简单明了——DevExpress 对于现实世界的 Web 应用程序是否足够快。我们在公司中使用 DevExpress 为客户构建 CRM，每个页面都有很多控件，而且速度非常慢。在我的开发服务器上，加载一个包含大约 20 个控件的页面需要 10 秒。这是好是坏？你们能不能给我指出一个真实的 DevExpress 应用程序，除了案例研究部分给出的应用程序。

Answer 1

我意识到这个问题已经很老了，原作者可能早就做出了决定。然而，当我的公司亲自指导我使用 DevExpress 并且我试图尽可能地获得所有性能时，谷歌搜索总是指向这个线程，并且在互联网上有很多人喜欢它。总会有一个问题，一些轶事回应，通常是 DevExpress 工作人员的公关回应。我很少从有经验的人那里找到诚实的答案。

过去，我使用过 Telerik、Infragistic 和 DevExpress。从性能和维护的角度来看，DevExpress 是最差的。他们所有的控件都有奇怪的属性和访问器，与熟悉 ASP.NET 甚至 HTML 的人所期望的不一致。由于控件的属性和访问器如此复杂，您会发现您编写的代码行数是普通 .NET 应用程序所需的代码行数的两倍。

DevExpress 控件呈现为非常臃肿的嵌套表。一些控件公开了更好的轻量级渲染模式，但它们的样式和功能与其他 DevExpress 控件不匹配，我发现它们在跨浏览器测试中存在很大问题。

由于控件属性的嵌套和隐藏特性，自定义样式需要许多自定义 CSS 选择器，这些选择器迫使您将 DevExpress 类名称编码到 CSS 中。这是非常糟糕的做法，因为 DevExpress 可以而且应该能够在他们认为合适的时候更改其内部 CSS 类名称。

这些控件还会向其提供资源的 DXR.axd 处理程序发出数量惊人的 GET 请求。

毫无疑问，他们的控件在屏幕上只显示 1 个控件的 Demo 环境中工作正常，但在现实世界中，这些控件很糟糕，应该避免。实现您自己的控件或仅下载 Bootstrap 并使用 native ASP.NET 控件。我用我创建的控件替换了 DevExpress，该控件为从 .NET 呈现的 native HTML 类型设置样式，下图说明了两者在资源使用方面的一些差异。这次交换的页面布局、业务层、数据层或数据库代码没有任何变化，只是替换了我之前优化过的 DevExpress 控件，并试图用我自己的控件挤出每一点性能。

Chart Comparing DevExpress to Custom Controls