Microsoft released ASP.NET 3.5 on November 19, 2007. Along with it, was released Visual Studio 2008. This evolution from ASP.NET 2.0 to ASP.NET 3.5 is quiet gradual. ASP.NET 3.5 uses the same engine as that of ASP.NET 2.0, with some extra features added on top of it. In this article, we will explore the new features added to ASP.NET 3.5. This article assumes that you have been working on ASP.NET 2.0.
New Features in ASP.NET 3.5
ASP.NET AJAX
In ASP.NET 2.0, ASP.NET AJAX was used as an extension to it. You had to download the extensions and install it. However in ASP.NET 3.5, ASP.NET AJAX is integrated into the .NET Framework, thereby making the process of building cool user interfaces easier and intuitive.
The integration between webparts and the update panel is much smoother. Another noticeable feature is that you can now add ASP.NET AJAX Control Extenders to the toolbox in VS2008. Even though this is an IDE specific feature, however I feel it deserves a mention over here for developers, who had to add extenders using source view earlier. It is also worth noting that Windows Communication Foundation (WCF) now supports JSON along with other standard protocols like SOAP, RSS and POX.
New Controls
The ListView and DataPager are new controls added along with a new datasource control called the LinqDataSource.
ListView
The ListView control is quiet flexible and contains features of the Gridview, Datagrid, Repeater and similar list controls available in ASP.NET 2.0. It provides the ability to insert, delete, page (using Data Pager), sort and edit data. However one feature of the ListView control that stands apart, is that it gives you a great amount of flexibility over the markup generated. So you have a complete control on how the data is to be displayed. You can now render your data without using the tag. You also get a rich set of templates with the ListView control. DataPager
DataPager provides paging support to the ListView control. The best advantage is that you need not have to keep it ‘tied’ with the control on which the paging is being done. You can keep it anywhere on the page.
DataPager gives you a consistent way of paging with the controls that support it. Currently only ListView supports it as it implements the IPageableItemContainer. However support is likely to be added to other List controls as well.
LINQ
LINQ (Language Integrated Query) adds native data querying capability to C# and VB.NET along with the compiler and Intellisense support. LINQ is a component of .NET 3.5. LINQ defines operators that allow you to code your query in a consistent manner over databases, objects and XML. The ASP.NET LinqDataSource control allows you to use LINQ to filter, order and group data before binding to the List controls.
You can learn more about LINQ over here. ASP.NET Merge Tool
ASP.NET 3.5 includes a new merge tool (aspnet_merge.exe). This tool lets you combine and manage assemblies created by aspnet_compiler.exe. This tool was available earlier as an add-on.
New Assemblies
The new assemblies that would be of use to ASP.NET 3.5 developers are as follows:
· System.Core.dll - Includes the implementation for LINQ to Objects
· System.Data.Linq.dll - Includes the implementation for LINQ to SQL
· System.Xml.Linq.dll - Includes the implementation for LINQ to XML
· System.Data.DataSetExtensions.dll - Includes the implementation for LINQ to DataSet
· System.Web.Extensions.dll: Includes the implementation for ASP.NET AJAX (new enhancements added) and new web controls as explained earlier.
Some Other Important Points
1. ASP.NET 3.5 provides better support to IIS7. IIS7 and ASP.NET 3.5 modules and handlers support unified configuration.
2. You can have multiple versions of ASP.NET on the same machine.
3. For those who are wondering what happened to ASP.NET 3.0, well there isn’t anything called ASP.NET 3.0.
4. VS 2002 worked with ASP.NET 1.0, VS 2003 worked with ASP.NET 1.1, and VS 2005 worked with ASP.NET 2.0. However VS 2008 supports multi-targeting, i.e it works with ASP.NET 2.0, and ASP.NET 3.5.
SQL Optimization Tips • Use views and stored procedures instead of heavy-duty queries.This can reduce network traffic, because your client will send toserver only stored procedure or view name (perhaps with someparameters) instead of large heavy-duty queries text. This can be usedto facilitate permission management also, because you can restrictuser access to table columns they should not see.• Try to use constraints instead of triggers, whenever possible.Constraints are much more efficient than triggers and can boostperformance. So, you should use constraints instead of triggers,whenever possible.• Use table variables instead of temporary tables.Table variables require less locking and logging resources thantemporary tables, so table variables should be used whenever possible.The table variables are available in SQL Server 2000 only.• Try to use UNION ALL statement instead of UNION, whenever possible.The UNION ALL statement is much faster than UNION, because UNION ALLstatement does not look for duplicate rows, and UNION statement doeslook for duplicate rows, whether or not they exist.• Try to avoid using the DISTINCT clause, whenever possible.Because using the DISTINCT clause will result in some performancedegradation, you should use this clause only when it is necessary.• Try to avoid using SQL Server cursors, whenever possible.SQL Server cursors can result in some performance degradation incomparison with select statements. Try to use correlated sub-query orderived tables, if you need to perform row-by-row operations.• Try to avoid the HAVING clause, whenever possible.The HAVING clause is used to restrict the result set returned by theGROUP BY clause. When you use GROUP BY with the HAVING clause, theGROUP BY clause divides the rows into sets of grouped rows andaggregates their values, and then the HAVING clause eliminatesundesired aggregated groups. In many cases, you can write your selectstatement so, that it will contain only WHERE and GROUP BY clauseswithout HAVING clause. This can improve the performance of your query.• If you need to return the total table's row count, you can usealternative way instead of SELECT COUNT(*) statement.Because SELECT COUNT(*) statement make a full table scan to return thetotal table's row count, it can take very many time for the largetable. There is another way to determine the total row count in atable. You can use sysindexes system table, in this case. There isROWS column in the sysindexes table. This column contains the totalrow count for each table in your database. So, you can use thefollowing select statement instead of SELECT COUNT(*): SELECT rowsFROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid <>
you can improve the speed of such queries in several times.
• Include SET NOCOUNT ON statement into your stored procedures to stop
the message indicating the number of rows affected by a T-SQL statement.
This can reduce network traffic, because your client will not receive
the message indicating the number of rows affected by a T-SQL statement.
• Try to restrict the queries result set by using the WHERE clause.
This can results in good performance benefits, because SQL Server will
return to client only particular rows, not all rows from the table(s).
This can reduce network traffic and boost the overall performance of
the query.
• Use the select statements with TOP keyword or the SET ROWCOUNT
statement, if you need to return only the first n rows.
This can improve performance of your queries, because the smaller
result set will be returned. This can also reduce the traffic between
the server and the clients.
• Try to restrict the queries result set by returning only the
particular columns from the table, not all table's columns.
This can results in good performance benefits, because SQL Server will
return to client only particular columns, not all table's columns.
This can reduce network traffic and boost the overall performance of
the query.
1.Indexes
2.avoid more number of triggers on the table
3.unnecessary complicated joins
4.correct use of Group by clause with the select list
5 In worst cases Denormalization
Index Optimization tips
• Every index increases the time in takes to perform INSERTS, UPDATES
and DELETES, so the number of indexes should not be very much. Try to
use maximum 4-5 indexes on one table, not more. If you have read-only
table, then the number of indexes may be increased.
• Keep your indexes as narrow as possible. This reduces the size of
the index and reduces the number of reads required to read the index.
• Try to create indexes on columns that have integer values rather
than character values.
• If you create a composite (multi-column) index, the order of the
columns in the key are very important. Try to order the columns in the
key as to enhance selectivity, with the most selective columns to the
leftmost of the key.
• If you want to join several tables, try to create surrogate integer
keys for this purpose and create indexes on their columns.
• Create surrogate integer primary key (identity for example) if your
table will not have many insert operations.
• Clustered indexes are more preferable than nonclustered, if you need
to select by a range of values or you need to sort results set with
GROUP BY or ORDER BY.
• If your application will be performing the same query over and over
on the same table, consider creating a covering index on the table.
• You can use the SQL Server Profiler Create Trace Wizard with
"Identify Scans of Large Tables" trace to determine which tables in
your database may need indexes. This trace will show which tables are
being scanned by queries instead of using an index.
• You can use sp_MSforeachtable undocumented stored procedure to
rebuild all indexes in your database. Try to schedule it to execute
during CPU idle time and slow production periods.
sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?')"
