Welcome to Imar.Spaanjaars.Com

Update 02/03/2009: There is now a VB.NET version of the application available thanks to Sven Huijbrechts from ClearMedia bvba. Check it out at the Downloads section at the end of this article

Note: this is part one in a series of six. If you rather read this entire series off-line, you can buy the series as a convenient PDF document that comes with the full source. Besides the convenience, buying the PDF will also make you feel good as it shows your appreciation for the articles and helps me pay the bills for my server and hosting so I can keep running imar.spaanjaars.com and continue to provide you with great content. For more details, check out this post that shows you how you can buy the entire series right now.

In January 2007 I released the first part of a highly popular three-part article series on N-Layer design using ASP.NET. This article was followed by two more parts in February, and I updated all three articles in April to fix some minor issues in the code and in the articles. In June 2007 I added another – small – article to the series that showed you how to do custom sorting in N-Layer applications.

Now, almost two years later, it’s time for a major update on the articles and the Contact Manager Application that is discussed in the article.

Over the next six articles, I’ll show you how I improved the design of the original application, making it more powerful, secure and easier to maintain.

This is part 1 in the series. It builds on top of the earlier three part series on N-Layer design. If you haven’t already done so, be sure to check out these articles first, as a lot of code and concepts used in this new series is explained in detail in the older series.

I recently got a couple of e-mails from people asking why I was storing unencrypted data in my web.config files for applications as the ones used in my N-Layer design examples.

The main reason is: I don't have much to hide. First of all, the web.config doesn't contain a lot of sensitive information. For example, I use Integrated Security in my database connections, so I don't have a need for clear text passwords. Secondly, the config files are stored on my machine in a safe way as only the Administrators group and the accounts used by the web server can access them. Finally, IIS and ASP.NET work together to block users from downloading the web.config file. (To see what I mean, try downloading this file: http://imar.spaanjaars.com/web.config. The file really exists on disk, but you get a 404 Not Found error nonetheless.)

But of course, your mileage may vary. Maybe you're afraid your client changes things they shouldn't change in the web.config file. Or maybe some of your co-workers can access the server through FTP to update the site but you don't want them to be able to change the settings. Or maybe you're afraid an employee of your ISP can read your sensitive data when your site is hosted in a shared hosting environment. In those cases, it's good to know it's very easy to encrypt sections of the web.config file.

It's not uncommon to set the ID of a Master Page in ASP.NET Programmatically. This is particularly useful when you have multiple master pages and want to have your CSS or JavaScript target specific control IDs in your code.

Without setting the ID property of the master page, a client side control ID may end up like this:

<input type="submit" name="ctl00$ContentPlaceHolder1$Button1" value="Button" 
id="ctl00_ContentPlaceHolder1_Button1" /> 

The ctl00 prefix on the id and name attributes represent the auto generated ID of the master page. Even if your page uses a different master, you may end up with the same prefix. Setting the server side ID of the master programmatically allows you to control the full control ID, making IDs predictable and thus more useable in client side code. For example, the following code in the code behind of the master page:

protected void Page_Init(object sender, EventArgs e)
{
  this.ID = "Master1";
}

<input type="submit" name="Master1$ContentPlaceHolder1$Button1" value="Button" 
id="Master1_ContentPlaceHolder1_Button1" /> 

This way you can assign a predictable master ID that your client side CSS and script can use.

If you use this trick, you have to be aware of when exactly to set the ID. Do it too late and you'll get in troubles.