ASP.NET developer categories

I was reading the ASP.NET developer categories. Writer describes the following three categories.

• The web developer
• The developer who build websites
• The ASP.NET super hero

Guest Writer on wijix.com

You have read my blog post here on programming360, but now I am also invited as guest writer on http://www.wijix.com/. So, you can also read my future posts on wijix blog.

Wijix.com is actually a group of independent technical writer. They are experienced architect and developer, who committed to bring and share innovative ideas and tips to the technical communities.

Some thoughts on Stored Procedure

I read Paul Nielsen post on stored procedure. According to him stored procedures are good for the applications. He is not only talking about logical or business process stored procedure, but he also encouraged developer for CRUD stored procedures. I think, it is good idea. There is no harm to use them. If database server have that capability, then why not CRUD stored procedures. Here I am quoting his valuable opinion.

The only real solution is an abstraction layer that fully encapsulates the database. Every database fetch, insert, and update must go through this access layer. Just as SOA provides this encapsulation for processes, the database needs the same black-box API. If the database team wants to refactor the database to improve some feature, it’s free to do so. If a new feature is added, the database team can add that feature and modify the API. It’s very clean, easy to refactor, and the database is now an on-ramp to the corporate roadmap.

If we look at the history of database development language, you will find either PL/SQL or T-SQL, these languages are not changed. As Paul made a cogent argument about T-SQL that it is still same for the stored procedure, which written decade ago.

I will appreciate you comments. Feel free to share your advice.

Data Access Layer Design Considerations

To help ensure that data access in your application is optimized for performance, there are several issues that you must consider and a number of decisions that you must make at design time:

• Design your data access layer based on how the data is used.


• Cache data to avoid unnecessary work.


• Connect by using service accounts.


• Acquire late, release early.


• Close disposable resources.


• Reduce round trips.


• Return only the data you need.


• Use Windows authentication.


• Choose the appropriate transaction type.


• Use stored procedures.


• Prioritize performance, maintainability, and productivity when you choose how to pass data across layers.


• Consider how to handle exceptions.


• Use appropriate normalization.

Reference: http://msdn.microsoft.com/en-us/library/ms998569.aspx

Extension Methods

Extension Methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.

I found a very good tutorial on Extension Method.

[Quick Tip] Session

During the development of Asp.Net application, developer don't need to instantiate any session. Session is automatically instantiated, you need to use them according to your requirement. Here, I am going to show you one simple example.

DataTable dt = new DataTable();

// what ever the table you want to put in dt

// assign dt value into session variable, make sure it is unique name,
// I have given dtSessionVariable as session variable name.
Session["dtSessionVariable"] = dt;


// To retrieve it from session, it require casting back to original type
DataTable dt = (DataTable)Session["dtSessionVariable"];

[Random Post] New Software Metric / WTF’s Per Minute

I saw following comic picture on stackoverflow.