ADGroup Verification in ASP.NET Web Applications

Normally in Enterprise level , users will be provided access at the ADGroup level for the application that are hosted at the intranet and internet. The web application will contains the access related code. There are two to check this access at ADGroup.
1. LDAP QUERY
2. Net inbuilt method

The first one LDAP approach is more time consumable. Also to add more value, we will be using a service account to pull the Active Directory information. This is risk, we are pulling firm sensitive data from the Active Directory. Moreover to check a single ADGroup, we are pulling all the existing and verifying it via loop. This is a bad practice. And causes Performance issues.

The Dotnet inbuilt function IsInRole is simplest way to achieve this. we need to know the domain name where the ADGroup is in place. The syntax for this goes like this.

bool IsHavingAccess = HttpContext.Current.User.Identity.IsInRole(domain\Adgroup);

This will help us to just verify the access security and provide the result. So by using this method, we are nowhere pulling sensitive information and logic will be very fast. Hope this helps.

CodeProject

ViewState Vs ControlState

we all know, in asp.net 1.x the web controls use the Viewstate to maintain state between postbacks. this involves more data to be transfered from and to the server. the best practice is to disbale ViewState when it is not required, but still this is problem in many other cases, suppose we use the DataGrid controls, which consumes most of the ViewState normally, the ViewState cannot be disabled because it has to support other events related to that control. the DataGrid page number, event command are stored in the Viewstate, so this is more inconvinient.
In Asp.Net 2.0, the Viewstate concept is changed and they have introduced the controlstate, which is a part of Viewstate, only for the purpose to maintain control state, not the content of it. Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality, whereas view state only contains state to maintain the control's contents (UI). Technically, control state is stored in the same hidden field as view state (being just another leaf node at the end of the view state hierarchy), but if you disable view state on a particular control, or on an entire page, the control state is still propagated. this enables us to use more Web Controls, as the viewstate is maintained internally. this will not support DataGrid, because it is part of Asp.Net 1.x, the new controls of Asp.Net 2.0 will support this feature. even the viewstate is disabled the event triggered, other control properties are maintained in the controls state.

The supported controls are listed below.
Control -> Properties Stored in Control State
CheckBoxList -> PreviousItemCount, PreviousOffset
ContentPager -> CurrentPage, PageCount
DetailsView -> PageIndex, Mode, DefaultMode
FormView -> PageIndex, Mode, DefaultMode
GridView -> EditIndex, SelectedIndex, PageIndex, SortDirection, SortExpression
ListControl -> SelectedIndices
(base class for BulletedList, CheckBoxList, DropDownList, ListBox, and RadioButtonList)
LoginView -> TemplateIndex
MultiView -> ActiveViewIndex
Table -> CurrentRow, ViewMode

Partial Classes

Partial Classes allow user to split the class file accross multiple source files. The benifit behind this approach is to hide the funtionality of the class. the same class can be created in may places and appropriate methods can be placed in the code file so that it derived classes can focus on significant part alone.

Optimizing performance with built-in types .Net

The runtime optimizes the performance of 32-bit integer types (Int32 and UInt32), so use those types for counters and other frequently accessed integral variables. For floating-point operations, Double is the most efficient type because those operations are optimized by hardware.

Dispose Vs Finalizer

The Dispose and Finalizer are methods used to clear the resources used for the object.
The Dispose is a method of IDisposable interface. we have to inherit this interface for our object and implement the method Dispose, to clear our objects used in our application. suppose if we use collection and dictionary or any other huge resource for a specific object, we have to clear all the memory used by the object when it is destroyed. to make this happen internallly for every object we have to implement Dispose method and it takes care of the clearing the memory.
The Finalizer method is also similar type but this will be called when GC gets invoked. this GC.Collect call will invoke Finalizer method for each and every object. this will do a emergency clean, it may lead to data loss some times.

we can also implement finalizer method as a special case. the call of finalizer method after a dipose is a waste of process time, we can bypass this action by setting the property SupressFinalizer to true. this will help to avoid calling the finalizer method when GC gets activated.

T-SQL Statement SET NOCOUNT ON

This one line of code, put at the top of a stored procedure turns off the messages that SQL Server sends back to the client after each T-SQL statement is executed. This is performed for all SELECT, INSERT, UPDATE, and DELETE statements. Having this information is handy when you run a T-SQL statement in a query window, but when stored procedures are run there is no need for this information to be passed back to the client.
By removing this extra overhead from the network it can greatly improve overall performance for your database and application.
If you still need to get the number of rows affected by the T-SQL statement that is executing you can still use the @@ROWCOUNT option. By issuing a SET NOCOUNT ON this function (@@ROWCOUNT) still works and can still be used in your stored procedures to identify how many rows were affected by the statement.
Microsoft even realized the issue that this creates and has changed the stored procedure templates from SQL Server 2000 to SQL Server 2005.

courtesy : - MSSQLTips.com

SQL Server

while using joins, Please remenber the keypoints,

1. use the primary key column and foreign key column of the table to create the join.
eg: EmpDeptID in Employee table with DeptID in Department table

2. the usage of other columns in the join will affect the performance of the query.

3. never use a variable in join condition, try to rewrite the same query with different join condition and use variable in the where.
eg: SELECT column1, colomn2 FROM Table1 T1 join Table2 T2
on T1.Col1 = T2.Col1 AND T1.Col2 = @Variable