This post is in continuation with the series started in my earlier post and continues to explore the remaining features as described in the post.
Let’s start by considering the point 2 in the earlier post i.e. Shrinking Session State
Shrinking Session State
ASP.NET (3.5) provides two default options for storing session state across a Web farm:
a session-state provider that invokes an out-of-process session-state server, and a session-state provider that stores data in a Microsoft SQL Server database.session state has to be serialized before it is sent to remote as both options involve storing state information outside a Web application's worker process
the size of the serialized data can grow quite large as more data is added to the session state.
ASP.NET 4 introduces a new compression option(compressionEnabled) .When this configuration option is set to true, ASP.NET will compress (and decompress) serialized session state by using the .NET Framework System.IO.Compression.GZipStream class.
This is depicted below.
<sessionState mode="SqlServer" sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate" allowCustomSqlDatabase="true" compressionEnabled="true"
/>
This seems like an excellent enhancement for making the Performance related issues a bit easier to tackle.
The next Enhancement will definitely add a lot in improving the performance of the applications. This is the Enhancement in Enabling/Disabling the Viewstate for Individual Controls.
Now the question raised, Is that really an enhancement. The answer is YES. This feature exists in the current 3.5 version also, however the enhancement in version 4.0 makes it a lot easier to manage.Let me explain it in detail.
Enabling View State for Individual Controls
In ASP.Net 3.5 and earlier Versions, view state is enabled for the page, with the result that each control on the page potentially stores view state. The View state is stored for each control even if it is not required for the application.
Why should we bother about the View state data?
View State data is included in the markup that a page generates and increases the amount of time it takes to send a page to the client and post it back. Now consider that all the controls save view state and it is not used in any processing. It will cause significant performance degradation.
Developers can disable view state for individual controls in order to reduce page size, but need to do it explicitly for individual controls.
In ASP.NET 4, all web server controls include a ViewStateMode property. This property disables view state by default and can be enabled for the controls that require it in the page.
The ViewStateMode property takes an enumeration that has three values: Enabled, Disabled, and Inherit.
Enabled enables view state for that control and for any child controls that are set to Inherit or that have nothing set.
Disabled disables view state, and Inherit specifies that the control uses the ViewStateMode setting from the parent control.
Let’s consider the Following Example
<form id="form1" runat="server">
<script runat="server">
protected override void OnLoad(EventArgs e) {
if (!IsPostBack) {
label1.Text = label2.Text = "Some Dynamic Value";
}
base.OnLoad(e);
}
</script>
<asp:PlaceHolder ID="plHolder1" runat="server" ViewStateMode="Disabled">Disabled:
<asp:Label ID="lblTest" runat="server" Text="ViewStateDisbaled" /><br />
<asp:PlaceHolder ID=" plHolder2" runat="server" ViewStateMode="Enabled"> Enabled:
<asp:Label ID="lblTest2" runat="server" Text="ViewStateEnabled" />
</asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />
In the Code above, view state for the plHolder1 control is disabled. The child label lblTest control inherits this property value (Inherit is the default value for ViewStateMode for controls.) and therefore saves no view state. In the plHolder2 control, ViewStateMode is set to Enabled, so lblTest2 inherits this property and saves view state.
The lblTest control (whose ViewStateMode value is set to Disabled) does not preserved the value that it was set to in code. However, the lblTest2 control (whose ViewStateMode value is set to Enabled) preserves its state.
ViewStateMode can also be set in @ Page directive
<%@ Page Language="C#" AutoEventWireup="true” CodeBehind="Default.aspx.cs"
Inherits="MyWebApp._Default" ViewStateMode="Disabled" %>
The Page class is just another control; it acts as the parent control for all the other controls in the page. The default value of ViewStateMode is Enabled for instances of Page. Because controls default to Inherit, controls will inherit the Enabled property value unless you set ViewStateMode at page or control level.
Having said the above point, let me emphasize here that the EnableViewState property of the Page still holds the upper hand i.e. If the EnableViewState is set to False and ViewStateMode is set to Enabled, no control will save the View state.
I’ll continue to explore the remaining Enhancements in the Next post.
Till Next we connect……
Happy Learning
Let’s start by considering the point 2 in the earlier post i.e. Shrinking Session State
Shrinking Session State
ASP.NET (3.5) provides two default options for storing session state across a Web farm:
a session-state provider that invokes an out-of-process session-state server, and a session-state provider that stores data in a Microsoft SQL Server database.session state has to be serialized before it is sent to remote as both options involve storing state information outside a Web application's worker process
the size of the serialized data can grow quite large as more data is added to the session state.
ASP.NET 4 introduces a new compression option(compressionEnabled) .When this configuration option is set to true, ASP.NET will compress (and decompress) serialized session state by using the .NET Framework System.IO.Compression.GZipStream class.
This is depicted below.
<sessionState mode="SqlServer" sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate" allowCustomSqlDatabase="true" compressionEnabled="true"
/>
This seems like an excellent enhancement for making the Performance related issues a bit easier to tackle.
The next Enhancement will definitely add a lot in improving the performance of the applications. This is the Enhancement in Enabling/Disabling the Viewstate for Individual Controls.
Now the question raised, Is that really an enhancement. The answer is YES. This feature exists in the current 3.5 version also, however the enhancement in version 4.0 makes it a lot easier to manage.Let me explain it in detail.
Enabling View State for Individual Controls
In ASP.Net 3.5 and earlier Versions, view state is enabled for the page, with the result that each control on the page potentially stores view state. The View state is stored for each control even if it is not required for the application.
Why should we bother about the View state data?
View State data is included in the markup that a page generates and increases the amount of time it takes to send a page to the client and post it back. Now consider that all the controls save view state and it is not used in any processing. It will cause significant performance degradation.
Developers can disable view state for individual controls in order to reduce page size, but need to do it explicitly for individual controls.
In ASP.NET 4, all web server controls include a ViewStateMode property. This property disables view state by default and can be enabled for the controls that require it in the page.
The ViewStateMode property takes an enumeration that has three values: Enabled, Disabled, and Inherit.
Enabled enables view state for that control and for any child controls that are set to Inherit or that have nothing set.
Disabled disables view state, and Inherit specifies that the control uses the ViewStateMode setting from the parent control.
Let’s consider the Following Example
<form id="form1" runat="server">
<script runat="server">
protected override void OnLoad(EventArgs e) {
if (!IsPostBack) {
label1.Text = label2.Text = "Some Dynamic Value";
}
base.OnLoad(e);
}
</script>
<asp:PlaceHolder ID="plHolder1" runat="server" ViewStateMode="Disabled">Disabled:
<asp:Label ID="lblTest" runat="server" Text="ViewStateDisbaled" /><br />
<asp:PlaceHolder ID=" plHolder2" runat="server" ViewStateMode="Enabled"> Enabled:
<asp:Label ID="lblTest2" runat="server" Text="ViewStateEnabled" />
</asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />
In the Code above, view state for the plHolder1 control is disabled. The child label lblTest control inherits this property value (Inherit is the default value for ViewStateMode for controls.) and therefore saves no view state. In the plHolder2 control, ViewStateMode is set to Enabled, so lblTest2 inherits this property and saves view state.
The lblTest control (whose ViewStateMode value is set to Disabled) does not preserved the value that it was set to in code. However, the lblTest2 control (whose ViewStateMode value is set to Enabled) preserves its state.
ViewStateMode can also be set in @ Page directive
<%@ Page Language="C#" AutoEventWireup="true” CodeBehind="Default.aspx.cs"
Inherits="MyWebApp._Default" ViewStateMode="Disabled" %>
The Page class is just another control; it acts as the parent control for all the other controls in the page. The default value of ViewStateMode is Enabled for instances of Page. Because controls default to Inherit, controls will inherit the Enabled property value unless you set ViewStateMode at page or control level.
Having said the above point, let me emphasize here that the EnableViewState property of the Page still holds the upper hand i.e. If the EnableViewState is set to False and ViewStateMode is set to Enabled, no control will save the View state.
I’ll continue to explore the remaining Enhancements in the Next post.
Till Next we connect……
Happy Learning
Comments
Post a Comment