DevExpress for ASP.NET足夠快

我的問題很簡單直接 - DevExpress足夠快，適用於真實世界的Web應用程序。我們在公司使用DevExpress爲客戶構建CRM，每個頁面都有很多控制，而且它的速度很慢。在我的開發服務器上，需要10秒才能加載大約20個控件的頁面。這是好還是壞？除了案例研究部分給出的內容外，你們能指點我一個真正的DevExpress應用程序嗎？DevExpress for ASP.NET足夠快

來源

2010-07-16 Soham Dasgupta

我們在這裏討論的是什麼樣的控件，以及您將多少數據輸入到此頁面？你是否100％確定這是控制渲染會讓你放慢速度？ – Paddy 2010-07-16 13:12:47

它們足夠快。 DevExpress網站使用DevExpress控件創建，從我的角度來看，它的工作速度足夠快。爲了幫助您提高性能，我們需要知道慢頁面上使用哪些控件，同時顯示多少數據，您用於測試的瀏覽器以及最終使用的DevExpress控件版本。

來源

2010-07-16 13:07:40

感謝您的信息，事實上我們需要很多我不否認的控件知識，但在21世紀使用表格呈現控件是一個缺點，根據我的觀點，爲什麼因爲整個Web社區都專注於HTML 5，CSS 3而不是表格。 – 2010-07-26 10:45:57

這很糟糕，但在分配責任時，我不會直接指向DevExpress控件 - 我將運行一個針對我的代碼的分析器來確定問題的真正目的。

來源

2010-07-16 13:10:32

Soham，

作爲一般規則，對於設計網頁的時候，儘量保持你的網頁的光，使他們能夠跑得更快。例如，你是否絕對需要一個頁面上的20個控件？

如果他們不需要任何特殊的功能，那麼你可以使用native rendering。

另外，看看我的文章DevExpress web.config settings to improve performance。

順便說一句，我爲DevExpress工作。 :)

來源

2010-07-16 19:03:00 Mehul

唉Mehul我們仍然在使用Vol 2009，我沒有看到我的公司升級得更早。 – 2010-07-26 10:47:38

Soham，如果您有機會，請使用最新版本的試用版來查看新版本是否可以爲您提供幫助。 :) – Mehul 2010-07-26 19:41:58

我沒有DevExpress的經驗，但你可能也想看看Improving Asp.net performance。它也可能有幫助。

來源

2010-07-16 19:06:43 mwgriffith

我意識到這個問題已經很老了，原來的作者可能早就做出了決定。然而，當我由我的公司親自指導使用DevExpress時，我試圖剔除所有可能的性能，Google搜索始終指向此主題，許多人喜歡通過互聯網。總有一個問題，一些軼事反應，通常是來自DevExpress的某人的PR反應。我很少從有經驗的人那裏找到誠實的答案

在過去，我使用了Telerik，Infragistic和DevExpress。從性能和維護角度來看，DevExpress是最糟糕的。他們的所有控件都有奇怪的屬性和訪問器，這些屬性和訪問器不符合熟悉ASP.NET甚至HTML的人所期望的內容。由於控件的屬性和訪問器太過複雜，因此您會發現您已經編寫了大約兩倍於普通.NET應用程序所需的代碼行。

DevExpress控件呈現爲非常龐大的嵌套表格。一些控件公開了一種更好的輕量級渲染模式，但其樣式和功能與其他DevExpress控件不匹配，我發現它們在跨瀏覽器測試中相當麻煩。

由於控件屬性的嵌套和隱藏特性，自定義樣式需要許多自定義CSS選擇器，這些自定義CSS選擇器強制您將DevExpress類名稱編碼到CSS中。這是非常糟糕的做法，因爲DevExpress可以並且應該能夠在他們認爲合適的時候更改其內部的CSS類名稱。

這些控件還會向提供資源的DXR.axd處理程序發出一個荒謬的GET請求數。

毫無疑問，他們的控件在Demo環境下工作正常，只有1個控件顯示在屏幕上，但在現實世界中，這些控件是可怕的，應該避免。實現自己的控件，或者下載Bootstrap並使用本機ASP.NET控件。我使用我創建的控件替換了DevExpress，這些控件樣式是從.NET呈現的本機HTML類型，下圖說明了這兩者之間資源使用情況的一些差異。對於此交換，頁面佈局，業務層，數據層或數據庫代碼沒有任何更改，只是替換了之前優化過的DevExpress控件，並試圖通過我自己的控件擠出每一點性能。

Chart Comparing DevExpress to Custom Controls

來源

2013-11-01 12:08:33

偉大的信息傑里米。即使我們選擇了DevExpress，僅僅是因爲它不是面向未來的。 – 2013-11-02 09:17:12

非常有趣，我分享你的觀點。我的公司剛開始使用DevExpress，並且在使用它一週後，我已經厭倦了它。就像你所描述的那樣，源代碼中產生了太多的不連貫和膨脹。您甚至無法輕鬆地在約會控件上創建自定義事件。這是完全混亂的，我只是想象未來人們如何設法保持這一點。之後實施新功能需要兩次甚至更多時間才能完成。 – DaveWut 2014-02-17 18:00:35

@DaveWut，跑吧，跑吧！距離我們決定擺脫使用DevExpress一年左右的開發已經過去將近兩年了，我們仍在努力清理這些混亂。他們到目前爲止是我們在Production中表現最慢的頁面，每當我必須維護或排除使用它編寫的頁面時，我都會感到恐懼。 – 2014-02-17 21:06:13

如果您使用包含文本框與formlayouts 20所控制，可能是服務器採取強硬的時間來呈現它長標籤的層次結構，包含頁面很多。 DevExpress在使用多個控件時不好。重寫一個ASPxTextbox控件可能需要KB，而在ASP.net Textbox控件上則需要數百個字節。

來源

2015-09-01 17:25:18 MC0de

2016 - 在過去的5年中，我依次使用了Infragistics，Dev Express，Telerik。

Infragistics我甚至不會開始，因爲它本身就是一個主題。

我與Dev Express最大的寵兒是他們的控件確實會在整體結果中增加一些「膨脹」。但是，一些控件確實具有值得誇大的功能集。當然，他們的Grid和Pivot網格是複雜的工具，可以讓用戶做很多事情，並且我已經成功實施了Devexpress包，這些包可以很快得到很好的結果。 Dev Express有兩個問題：

每當我安裝一個新版本時，它會破壞大量的代碼，這是WebForms和MVC實現。這是相當令人沮喪的，但作爲程序員我預計我的預期。
他們真的看起來不太好，你必須通過很大的努力去尋找接近自舉表等東西。一旦完成，但他們確實允許所有需要的鐘聲和哨聲。當然，正如上面的作者建議自己發展一樣，這總是一種選擇，但這不是人們購買控制的原因。他們正在試圖利用他們的時間，以便他們可以更快地實施。

說完這一切，Telerik是目前最好的品種，在我看來目前爲止。更容易實施，網格速度快，具有適當的理想功能並且看起來更好。

來源

2016-10-24 16:06:25 Robert

-1

入口頁有20多個控件非常普遍。我確實使用了devexpress多年，速度和性能都可以接受。我們用來構建ERP解決方案。

來源

2017-01-04 15:35:22 mokth

DevExpress for ASP.NET足夠快

回答

相關問題