Zeeshan Hirani

If you would like to build your queries based on existing queries, it is essential that you use object initializer instead of using non default constructor. The reason is non default constructors have no direct translation in SQL server. Therefore you cannot further reuse your queries and you would have to force rest of the query to be executed in memory. Here is an example that illustrates this behavior.

Today I was working on a class library(someone else wrote) that used Linq extensively. One of the problems I noticed was, there was no reuse of queries in the class. Every method pretty much return List<T> where T was a custom class that was created by joining three Linq to SQL tables. Here is an example of that.

In the application that I am currently working, the user interface allow the end user to select multiple items and mark them for deletion. After marking them for deletion they have to click the submit button to send the changes to the database. Well, I had the those objects in memory so I simply passed those objects to DeleteAllOnSubmit method exposed on datacontext and called submitchanges. I thought that linq to SQL would issue a single statement to the database to delete all those objects but it issued seprate SQL statement to delete each object. Here is an example that illustrates the behavior.

Although DataSet provides some querying capabilities using its Select method but the usage is very limited and the result is not strongly typed. Using Linq to DataSet extensions you can apply unlimited querying capabilities and also transform your DataSet into strongly typed objects. Here is an example where I am returning products collection from a DataSet and also applying a filter on the DataSet to return products rows that belong to category of beverage.

If you are trying to find items selected in a ListBox, you could do it the old fashioned way by looping through list items and checking to see if item is selected and if the item is selected you grab the selected value and create an instance of the object, assign the selected value to the object and add the object to the collection. However a simple query makes this entire process only 1 liner. Here is the code that I used to grab selected items from a ListBox.

If you ever wanted to return an empty collection instead of returning null, you can use Enumerable.Empty. The Enumerable.Empty creates an empty collection of correct type specified by the generic parameter. Here is an example of returning generic empty collection.

I was surprised that SiteMapPath control is screen reader friendly. It exposes a property called SkipLinkText whose value defaults to "Skip Navigation Links". When screen reader starts reading the page it will ignore all the links and only read the text specified on SkipLinkText. If you want screen reader to read a different text than what its default to, simply change the text to the content that you want the screen readers to read. The text you specify for SkipLinkText property will not effect you regular html rendering.

In the past, if I had to access specific property of a master page from my content page, I usually would cast my master page to right type and get access to property but this could lead to runtime errors. Today I discovered that you can apply master type directive on your content page to make your master page reference strongly typed. Once you apply the MasterType directive, you no longer have to cast the Master Page to correct type because it is casted to the right type already. Here is snippet that you can put in your content page.