1. Right-click your start-up project in Studio and click Browse With…
2. Click Add
3. Click the Browse button beside Program Name
4. Select the browser you wish to use
5. Click Ok
6. Select the browser you just added and click Set as Default

Here are the install locations of some of the more common browsers:

• Firefox: C:\Program Files\Mozilla Firefox
• Chrome: C:\Documents and Settings\UserName\Local Settings\Application Data\Google\Chrome\Application
• Safari: C:\Program Files\Safari
• Opera: C:\Program Files\Opera
• IE: C:\Program Files\Internet Explorer

I find myself using Firefox the most, followed by Chrome. And as a best practice, don’t forget to test your projects in all browsers before putting them into production!

Two Common, But Easily Correctable Problems

Two of the most common problems I’ve seen in databases are a lack of primary and foreign key constraints and poorly typed data. These problems can and will lead to performance issues, and even worse, bad data. Luckily, these are also two of the easiest problems to correct.

Keys

If you want to increase the performance of your database, then here’s a great starting point. Make sure that your tables have keys. EVERY table should have at least a primary key. But you shouldn’t stop there; you should also have foreign key constraints on many of your tables (keep in mind we call them “relational databases” for a reason – so create some relationships between the tables!). This has two benefits.

The first is the preservation of data integrity. Consider a simple example for a moment – two tables, Members and Address. The Members table has 2 columns, Id and MemberName. The Address table has a MemberId column and all the expected fields for addresses. Let’s suppose there is an undetected bug in an application that updates or inserts to these tables. Now think about the application that would consume the data. What happens when two members have the same ID? What about when the MemberId in the Address table doesn’t correspond to an actual Id in the Members table?

In software development, bugs are an unfortunate reality. Having strict key constraints in your database will add an additional degree of safety to your applications. In our example above, the Members table should have the Id column marked as a primary key and the Address table should have it’s MemberId column marked as a foreign key to the Member table’s Id field.

The second benefit is increased performance. Foreign keys will help the optimizer establish relationships between tables and primary keys will auto-generate a clustered index on the table. I’ll touch on this in more detail later in this post as well as in my next post but these both offer gains in performance.

Data Types

Another common problem is poorly typed data. An extreme example of this is every column in a table being labeled as varchar(max) and allowing nulls, but lesser offenses can still cause problems. Pay attention to the type, max length, and nullability of your columns and make wise decisions in setting these properties. In general, your decisions should demonstrate simple logic – use varchar(2) instead of varchar(max) if you’re storing State abbreviations, use int instead of varchar if you’re storing a number, etc.

An Example

Both of these concepts are easy to demonstrate. If you have access to a testing environment, run the following script to create a couple of test tables.

CREATE TABLE [dbo].[WidgetDescription]
(
    [Id] [varchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    [ItemName] [varchar](255) COLLATE  SQL_Latin1_General_CP1_CI_AS NOT NULL,
    [Description] varchar(255) COLLATE  SQL_Latin1_General_CP1_CI_AS NOT NULL
)
GO

CREATE TABLE [dbo].[WidgetCount]
(
    [Id] [varchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    [WidgetId] [varchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    [NumberProduced] varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
)

DECLARE @i int
SET @i = 0

WHILE @i < 100000
BEGIN
    INSERT INTO [WidgetDescription] (Id, ItemName, Description)
    VALUES (cast(@i as varchar), 'Widget' + cast(@i as varchar), 'Description of the Widget')

    INSERT INTO [WidgetCount] (Id, WidgetId, NumberProduced)
    VALUES (cast(@i as varchar), cast(@i as varchar), cast(@i as varchar))

    SET @i = @i + 1
END

We’ve created 2 (poorly designed) tables that contain information about widgets. Now let’s examine some simple queries. Note that I’m using STATISTICS TIME to monitor the run-time of the queries. To see this information, click the Messages tab in the output when the query is complete.

SET STATISTICS TIME ON
SELECT NumberProduced FROM WidgetCount WHERE WidgetId = 1
SET STATISTICS TIME OFF

SET STATISTICS TIME ON
SELECT Description FROM WidgetDescription WHERE Id = 1
SET STATISTICS TIME OFF

My average run-time for the queries is in the 24 ms and 26 ms range, respectively.

Run Time of our 2nd query before any optimizations

Now let’s take some simple measures to improve the tables and see the difference it makes. First we’ll just make some simple data-type changes to the WidgetCount table. Our columns are meant to represent numbers, so they should all be of type int. For the WidgetDescription table, we’ll make similar data type changes and add a primary key. Make the Id column an int, set it to Identity with auto-increment, and make it a primary key. Shorten the ItemName column to only allow 25 characters and shorten the Description column to allow 100. (In a production environment, we would also set up a foreign key constraint between the WidgetId column of the WidgetCount table and the Id column of the WidgetDescription table, but this isn’t necessary for this example.)

The same query after applying primary key and data type changes

Now run the queries again, and you should see run-times averaging around 8 ms and 1 ms respectively. As you can see, changing the data types boosted performance, and adding a primary key additionally boosted performance. If a difference of a few milliseconds doesn’t seem like a big deal, try thinking of it this way. In the second query, making a few simple changes to our table resulted in a performance boost of 2500%. That is indeed a big deal. It might not be so noticeable when dealing with milliseconds, but when you bring a query that takes 10 seconds to run down to under 1, it will be.

So how do we explain this boost? Two things. As for the data types, ints use less disc space for storage than varchars, and varchar(25) and varchar(100) use less than varchar(255). So there is simply less physical data to actually inspect and return. But the bigger difference is the primary key. Without the key, the optimizer can’t know that the values in the Id column are unique. So even though it finds a match after examining one row of data, it has to look at the other 99,999 to make sure there isn’t another match. However, once we add the key constraint, the optimizer knows it can stop looking after it finds a single match. The optimizer is doing a table scan (slow) in one instance and an index seek (fast) in the other. Again, I’ll cover this in more detail in my next post.

To summarize, I’ve outlined two very easy rules to follow to ensure that your databases are well designed. You should also start to see some performance boosts as a result of enforcing these rules. In my next post, I’ll show you how to examine the optimizer’s execution plan to create indexes on your tables in order to further improve your database’s performance.

To get around this conundrum, I present to you jquery and ajax, my two favorite web technologies ever. AJAX is a group of technologies that allows you to interact with the server from the client-side without affecting the behavior of the existing page. What this means is that you can post to a page without getting the associated postback from .NET (and subsequent page refresh). If that doesn’t sound important, trust me, it is. If we can post to a page without getting a postback, then we’re already pretty close to real-time updates. All we need to do now is use jQuery to update the DOM as we do posts. Sound complicated? It isn’t.

Back to our example, suppose a user clicks a button and that button fires a postback and runs 3 methods in the code-behind, DoStep1(), DoStep2(), and DoStep3(). The first thing we need to do is simply move these methods to a new page. If your original page was called DoWork.aspx, then a good name for the new page would be DoWork_Ajax.aspx.

Now, back on DoWork.aspx, you probably have an asp element on your page that you’d like to update as the functions progress. You can replace this with a standard HTML element. DoWork() is a javascript function that will update this element. It looks like this:

function DoWork(step)
{
    if (step == 1)
    {
        $("#update-msg").html("Starting Work");
    }

    if (step == 4)
    {
        $("#update-msg").html("Finished");
        return false;
    }        

    $("#update-msg").load(
        "DoWork_Ajax.aspx #results span",
        { workStep: step },
        function(){ DoWork(step + 1); }
    );
}

Assume that #update-message is a span on our page, i.e. a placeholder for the status of our worker functions.

The logic flows as such: If we’re on step 1, tell the user we’re starting. If we make it past step 3, we’re done, so tell the user that too and return from this function. Finally, the meat of the function – Do an asyncronous post to DoWork_Ajax.aspx, telling it what step we’re on, and injecting a span from it into the DOM for the current page.

The PageLoad method for DoWork_Ajax.aspx looks like this:

switch (Request["workStep"])
{
    case "1":
        DoStep1();
        break;
    case "2":
        DoStep2();
        break;
    case "3":
        DoStep3();
        break;
}

Each method updates an element on the page, just like before. This is the element that gets injected into the DOM by our jQuery function on DoWork.aspx.

You’re doing the exact same work as before, but now you can update the page in real time. I’ve included a sample application that demonstrates everything I’ve talked about. For those that are interested, you can download the project and run it locally to see this in action.

Luckily a solution exists, and best of all it isn’t all that difficult to implement. The solution is built around the idea that child pages can access their master page, as well as any publicly exposed properties on the master. For example, in the Page_Load method of a child page, you can write:

MyMasterPage masterPage = Master as MyMasterPage;
masterPage.Property = “property value”;

This is not ideal though, because we are now committed to never changing our child’s master page; if we do, it will break our build. The correct implementation of this concept is to create an interface that all of our master pages will implement, then use that in our child pages’ Page_Load method:

IMasterPage masterPage = Master as IMasterPage;
masterPage.Property = “property value”;

We can still set our property this way, only now we can later change what master page we use, as long as the new one still implements the same interface. Good stuff. So good, that it puts us most of the way there towards dynamic body ids and classes.

To get these, we need a couple of properties on our interface:

public interface IMasterPage
{
     String BodyId { get; set; }
     String BodyClass { get; set; }
} 

Then, in the code-behind file for our actual master page:

public partial class MasterPagesDefault : MasterPage, IMasterPage
{

    private string _bodyId;
    private string _bodyClass;

    public string BodyId
    {
        get { return _bodyId; }
        set { _bodyId = value; }
    }

    public string BodyClass
    {
        get { return _bodyClass; }
        set { _bodyClass = value;}
    }
} 

Finally, in the master page’s body tag:

<body id="<%= BodyId %>" class="<%= BodyClass %>">

Now, to set these dynamically, use the child page’s Page_Load method just like before:

IMasterPage masterPage = Master as IMasterPage;
if (masterPage != null)
{
    masterPage.BodyId = “index”;
    masterPage.BodyClass = “index two-col”;
} 

By using publicly accessible properties, we give child pages the ability to set values on their master page. With this, it is easy to create dynamic body classes and ids in .NET.

To start things, I made a simple payment gateway interface to make sure my gateway objects will do the one thing I need them to:

public interface IPaymentGateway
{
    string SubmitPayment(Payment payment);
}

Essentially what I’m saying here is that no matter what type of gateway I’m using, I’ll need to submit a payment.

Next, we have a simple factory pattern to return some type of gateway:

public class PaymentGatewayFactory
{
    public IPaymentGateway CreatePaymentGateway()
    {
        PaymentGatewayRepository paymentGatewayRepository = new PaymentGatewayRepository();
        string gatewayType = paymentGatewayRepository.GetGatewayType();

        switch(gatewayType)
        {
            case "Authnet":
                return new Authnet();
            case "Paypal":
                return new Paypal();
            case "Payflow":
                return new PayflowPro();
            default:
                throw new NotSupportedException("This payment gateway is not supported.");
        }
    }
}

Here we have a call to a PaymentGatewayRepository class (not included), which will read a config file and return a string representing what type of payment gateway the client is using. Next, a simple switch is done that will return the appropriate payment gateway class (or a custom exception if the gateway is not yet supported). Each of the gateway classes implements the IPaymentGateway interface.

The beauty of this is that once this project is built, submitting payments is a breeze. Just include the assembly in a project, reference it, and then follow these three easy steps:

1. Add the necessary config keys.

   <!-- Gateway types | Possible Values: Authnet, Paypal, Payflow -->
   <add key="GatewayType" value="Authnet">
   
   <!-- Authnet Keys -->
   <add key="Anet_URL" value="https://test.authorize.net/gateway/transact.dll"/>
   <add key="payment_login_key" value="123456789"/>
   <add key="payment_tran_key" value="987654321"/>
   <add key="payment_auth_name" value="Example"/>

2. Build the payment object.

   Payment payment = new Payment();
   payment.BillingFirstName = "Jeremy";
   payment.BillingLastName = "Wiggins";
   
   etc…

3. Submit the payment.

   IPaymentGateway gateway = new PaymentGatewayFactory().CreatePaymentGateway();
   gateway.SubmitPayment(payment);

And that’s all there is to it. This will be a nice addition to a reusable component library. Once the logic has been implemented for a new payment gateway, it never has to be thought about again. Just add a few lines to a config file and submit payments in a couple of easy steps.