對於你所有的ASP.NET專家和初學者,你是否將狀態管理視爲一項困難而煩人的任務?如果你重新開始使用ASP.NET,你會考慮使用ASP.NET MVC,而不必再次處理ViewState?ASP.NET狀態管理可以讓初學者望而生畏?
此外,是否真的,一旦你去了ASP.NET MVC,你永遠不會回到ASP.NET Webforms(除非你的工作需要)?
對於你所有的ASP.NET專家和初學者,你是否將狀態管理視爲一項困難而煩人的任務?如果你重新開始使用ASP.NET,你會考慮使用ASP.NET MVC,而不必再次處理ViewState?ASP.NET狀態管理可以讓初學者望而生畏?
此外,是否真的,一旦你去了ASP.NET MVC,你永遠不會回到ASP.NET Webforms(除非你的工作需要)?
對於初學者來說ViewState並不是一件令人望而生畏的事情,對於專家來說是艱鉅的。 ViewState非常棒,因爲它爲初學者程序員混淆了狀態管理,並允許他們專注於編寫代碼。然後,當他們需要編寫更高級的東西並且意識到ViewState具有嚴格的侷限性和缺點,但他們不知道如何做其他事情時,它會再次困擾他們。
對於ASP.NET WebForms,我必須承認,我首先完全放棄了ASP.NET MVC(除了支持一些傳統應用程序),但最近發現自己已經返回到ASP.NET以用於較小的項目。如果我需要快速而又髒的東西,我通常會轉向WebForms。如果事情更大,我將不得不保持下去,我發現MVC更具吸引力。
我認爲ViewState是狀態管理的一個子集。我現在不嘗試處理ViewState,只有在我(通常)處理遺留頁面或項目時才使用它。我認爲它非常邪惡......但不幸的是,它有時最終成爲必要的罪惡。
對於許多Web應用程序來說,狀態管理是必要的,並且不是非常困難或令人討厭的實現,因爲有適當的框架。 MVC也支持國家管理。
我也認爲是否使用MVC或WebForms取決於需求。可能有理由去WebForms。當新的東西出現時,我不相信會註銷技術 - 你永遠不知道什麼時候你會再次需要它。
我認爲webForms只是一個令人討厭的技術。 如果你有選擇去與MVC你永遠不會去與webForms。
我寧願Asp.net MVC任何一天在ASP.net Webforms。通過webforms,開發人員有興趣編寫意大利麪代碼。