Separation of Code from Content
As I mentioned previously, a major drawback of ASP in certain instances is that there is no way to separate code from page content. In ASP.NET, due to the introduction of server controls and the event-driven model, the trend leans toward placing all the code in event handlers in one place in the file (normally at the top). If this isn't sufficient, it's also possible to totally separate code from content by placing all the code in a separate file (VS .NET does this by default).
Session State Management
ASP provided a special collection object where the programmer could store variables pertaining to a particular visitor's session. This was a commonly used feature, but it had three major shortcomings. First, it wasn't Web farm-friendly. Session state variables were stored in the IIS process space, and as such, they were tied to a specific machine. Thus, if a visitor to a site had a particular piece of information stored in a session variable on a particular request, and he or she was then sent to another server on the next request, the ASP code would not be able to retrieve the previously stored
value. Second, a disadvantage of storing session state in the IIS process space is that should the IIS service have to be restarted, the session information is lost. The third problem was slightly more subtle, but important nonetheless: ASP kept track of visitor IDs by using cookies, which aren't supported by all browsers, or are not guaranteed to be enabled in all user browsers.
As I mentioned previously, a major drawback of ASP in certain instances is that there is no way to separate code from page content. In ASP.NET, due to the introduction of server controls and the event-driven model, the trend leans toward placing all the code in event handlers in one place in the file (normally at the top). If this isn't sufficient, it's also possible to totally separate code from content by placing all the code in a separate file (VS .NET does this by default).
Session State Management
ASP provided a special collection object where the programmer could store variables pertaining to a particular visitor's session. This was a commonly used feature, but it had three major shortcomings. First, it wasn't Web farm-friendly. Session state variables were stored in the IIS process space, and as such, they were tied to a specific machine. Thus, if a visitor to a site had a particular piece of information stored in a session variable on a particular request, and he or she was then sent to another server on the next request, the ASP code would not be able to retrieve the previously stored
value. Second, a disadvantage of storing session state in the IIS process space is that should the IIS service have to be restarted, the session information is lost. The third problem was slightly more subtle, but important nonetheless: ASP kept track of visitor IDs by using cookies, which aren't supported by all browsers, or are not guaranteed to be enabled in all user browsers.
