在ASP.NET，Webforms或MVC中使用ExtJS？

對於使用0個ASP.NET控件而不是100％extJS接口的場景，使用ASP.NET MVC或ASP.NET WebForms的優勢是什麼？和缺點？有沒有一種明顯的方式來正確地做到這一點？在ASP.NET，Webforms或MVC中使用ExtJS？

我很樂意聽取您的經驗反饋。

謝謝！

來源

2009-11-12 TigrouMeow

WebForms +任何純粹的客戶端框架只會給你帶來無窮無盡的頭痛，如果你能使它工作的話。有些我已經在過去的問題（我的頭的頂部，它已經有一段時間）：

的WebForms限制你到每頁一個<form>標籤。雖然這並不一定能防止使用分機的或類似的東西，它是嚴重（和任意）在許多情況下
的WebForms是建立在回發和視圖狀態限制。假設你沒有使用這些功能（因爲你沒有服務器控件），你將會反對WebForms想要的工作方式。你可以做到這一點，但事情很快就會變得很糟糕。
的WebForms有一整頁的生命週期和服務器端事件的框架。再說一次，既然你不會使用這些，那麼選擇WebForms有什麼意義呢？
你堅持討厭的網址，除非你想真正與IIS戰鬥。

如果您仍然想利用.NET在服務器端可以提供的優勢，而沒有WebForms的痛苦，那麼ASP.Net MVC是一個更好的選擇。如果您搜索，也可以在Ext論壇中找到幾個不同的Ext.Direct提供商用於MVC。祝你好運找到任何東西，以幫助您將Ext與WebForms集成（沒有任何內容）。

編輯：我一直在爲ASP.NET MVC使用Ext.Direct堆棧的this implementation一段時間，結果很好。

來源

2009-11-12 02:47:15

爲此，我傾向於使用ASP的MVC風格。基本上這是因爲ASP.net往往會添加你不需要的隨機垃圾。你想要的是將數據推送到ExtJS的最純淨的東西。如果你根本不需要任何服務器交互，假設你發送的任何內容都返回到Azure或S3，那麼你根本不需要任何ASP就可以發送靜態HTML。

來源

2009-11-12 01:56:06 stimms

另一種觀點：我建立一個Web客戶端在ExtJS的一個特定領域的.NET服務器遠程處理。我想我可以基本上只是推「原始」數據爲EXT作爲服務器應用程序處理所有的邏輯，但由於我的遠程不是「網絡意識」，我使用了一組自定義HTTP處理程序（ashx的）來解析參數和設置MIME類型，會話處理和所有與網絡服務器相關的東西。在此架構下的工作非常好，只是一個few.ashx腳本，我不覺得任何需要使用像ASP.NET MVC票友設置（我甚至不認爲這適合），但我不使用的WebForms無論是。

來源

2009-11-12 08:13:45 Tewr

考慮將您的Ext JS前端與服務器隔離開來。

此解耦強制您創建一個純JavaScript應用程序，並使您遠離各種框架中「助手」引入的問題。

它減少了時間服務器端語言和JavaScript之間你會被「換擋」的量。根據我的經驗，特別是對於新的Ext JS開發人員來說，最大的障礙是將前端邏輯與服務器端邏輯分開。

而且它會快速發展！使用純HTTP和JSON與服務器通信，並按照預期構建Ext JS應用程序！

來源

2009-11-12 20:15:54

對於單頁「胖客戶」類型的應用程序，這絕對是唯一的選擇。 – neonski 2009-11-12 20:39:36

ASP.Net MVC更適合與ExtJs集成。如果你必須使用Web窗體，那麼我建議看看http://www.coolite.com/。這是一個關於ExtJs的ASP.Net包裝器，可能會使生活更輕鬆。

來源

2010-05-31 22:57:15 ravi

在ASP.NET，Webforms或MVC中使用ExtJS？

回答

相關問題