•View State weight: the particular mechanism for maintaining state across requests (known as view State) resulted in massive blocks of knowledge being transferred between the consumer and server. This information might reach many kilobytes in even modest web applications, and it went back and forth with each request, resulting in slower response times and increasing the information measure demands of the server. • Page life cycle: The mechanism for connecting client-side events with server-side event handler code, a part of the page life cycle, might be difficult and delicate. Few developers had success manipulating the management hierarchy at run time while not creating read State errors or finding that some event handlers enigmatically did not execute. • Separation of concerns: ASP.NET net Forms’ code-behind model provided a method to require application code out of its hypertext mark-up language markup and into a separate code-behind category. This was done to separate logic and presentation, but, in reality, developers were inspired to combine presentation code (for example, manipulating the server-side management tree) with their application logic (for example, manipulating info data) in these same monstrous code-behind categories. The end result may well be fragile and unintelligible. •Restricted management over hypertext markup language: Server controls rendered themselves as HTML, but not necessarily the markup language you needed. In early versions of ASP.NET, the hypertext markup language output failed to meet net standards or keep use of Cascading vogue Sheets (CSS), and server controls generated unpredictable and complicated ID attributes that were exhausting to access victimization JavaScript. These issues have improved in recent net Forms releases, however it will still be difficult to induce the markup language you expect. •Abstraction: net Forms tried to cover markup language and hypertext transfer protocol where doable. As you tried to implement custom behaviors, you often fell out of the abstraction, which forced you to reverse-engineer the post back event mechanism or perform obtuse acts to create it generate the required markup language. • Low test-ability: The designers of net Forms couldn't have anticipated that automated testing would become a vital element of package development. The tightly coupled design they designed was unsuitable for unit testing. Integration testing may well be a challenge, too. Sagar Jaybhay
.Net web forms: - .NET Web Forms was born from an attempt to address the ever looming issue implicit in the development of classic ASP websites. It has few disadvantages:- 1. Disadvantages of .NET Web Forms: Very little control over HTML produced on the page - The ability to simply drag & drop controls enables rapid application development (RAD), but the drawback is that the developer has very little control over what HTML is actually produced on the page. Web Forms Life Cycle - A lot of developers must become acquainted with the more esoteric lifecycle events as a result of needing to “hook” into 3rd party controls. Jimmy Wick
