July 2008 Entries

• Use the <%@ MasterType %> page directive so you do not have to cast Master to your type.
• Public events on the master are a simple way to hook into the consumer.
• Register handlers of the master's events in the consumer's Page_PreInit.  This will ensure that the handlers are in place plenty of time before the master needs them.
• Think twice before you copy-paste your UI code.

Now, I'm going to go see if there are other pages in my application with similar behavior that can be improved with master pages.

    1 public abstract class MyBaseController<T> where T : IMyBaseView

    2 {

    3     protected IMyDataContext _dataContext;

    4     protected T _view;

    5 

    6     public virtual void Observe( T view, IMyDataContext dataContext )

    7     {

    8         _view = view;

    9         _dataContext = dataContext;

   10 

   11         if( !_view.IsPostBack )

   12         {

   13             PreInitializeView();

   14             InvalidateCache();

   15             InitializeView();

   16         }

   17         else

   18         {

   19             UpdateView();

   20         }

   21         AttachEvents();

   22     }

   23     ...

   24 }

    1 public interface IMyConcreteView : IMyBaseView

    2 {

    3     event EventHandler Added;

    4     event EventHandler Edited;

    5     event EventHandler Deleted;

    6 }

    7 

    8 public class MyConcreteController : MyBaseController<IMyConcreteView>

    9 {

   10     protected override void AttachEvents()

   11     {

   12         base.AttachEvents();

   13         _view.Edited += new EventHandler( _view_InvalidationEvent );

   14         _view.Added += new EventHandler( _view_InvalidationEvent );

   15         _view.Deleted += new EventHandler( _view_InvalidationEvent );

   16     }

   17     ...

   18 }

Sure, I could have introduced a local "view" property that casts the base view to my concrete view, but do I really want to do that for all of my controllers.  I'm thankful that generics can do the work for me.

Despite "The Cost of Premature Optimization", it's useful to know how things work so you can do basic things to avoid bad performance.  In the end, the example below is trivial and doesn't have a significant effect on performance (at least as it applies in my application).  However, knowledge of IEnumerable and yield can come in handy when it really counts.

As I was writing a bit of code, I wondered if order matters when it comes to query expressions.  Specifically, I have an enumerable that I was applying a Where and OrderBy to.  Ultimately, I was selecting the first item from the result.

I came back to the code later and decided to write an experiment.  What would happen if I changed the order of the Where and OrderBy?

   1: [Test]

   2: public void TestExperiment()

   3: {

   4:     IEnumerable<int> numbers = new[] { 3, 16, 2, 19, 14, 5, 20, 8, 11, 7, 13, 6, 12, 9, 4, 15, 10, 18, 1, 17 };

   5:     var composite = from number in numbers

   6:                     select new { Number = number, Date = DateTime.Today.AddMonths( number ) };

   7:     int whereCount;

   8:     int orderByCount;

   9:     Console.WriteLine( "IEnumerable<Anonymous> : Comparing Anonymous.Date" );

  10:     Console.WriteLine();

  11:     Console.WriteLine( "Compare <= " );

  12:     Console.WriteLine( "Where then OrderBy" );

  13:     whereCount = 0;

  14:     orderByCount = 0;

  15:     composite

  16:         .Where( test =>

  17:             {

  18:                 whereCount++;

  19:                 return test.Date <= DateTime.Today.AddMonths( 5 );

  20:             } )

  21:         .OrderBy( test =>

  22:             {

  23:                 orderByCount++;

  24:                 return test.Date;

  25:             } )

  26:         .First();

  27:     Console.WriteLine( "    Where:" + whereCount );

  28:     Console.WriteLine( "    OrderBy:" + orderByCount );

  29:     Console.WriteLine( "OrderBy then Where" );

  30:     whereCount = 0;

  31:     orderByCount = 0;

  32:     composite

  33:         .OrderBy( test =>

  34:             {

  35:                 orderByCount++;

  36:                 return test.Date;

  37:             } )

  38:         .Where( test =>

  39:             {

  40:                 whereCount++;

  41:                 return test.Date <= DateTime.Today.AddMonths( 5 );

  42:             } )

  43:         .First();

  44:     Console.WriteLine( "    Where:" + whereCount );

  45:     Console.WriteLine( "    OrderBy:" + orderByCount );

  46:     Console.WriteLine();

  47:     Console.WriteLine( "Compare >= " );

  48:     Console.WriteLine( "Where then OrderBy" );

  49:     whereCount = 0;

  50:     orderByCount = 0;

  51:     composite

  52:         .Where( test =>

  53:             {

  54:                 whereCount++;

  55:                 return test.Date >= DateTime.Today.AddMonths( 5 );

  56:             } )

  57:         .OrderBy( test =>

  58:             {

  59:                 orderByCount++;

  60:                 return test.Date;

  61:             } )

  62:         .First();

  63:     Console.WriteLine( "    Where:" + whereCount );

  64:     Console.WriteLine( "    OrderBy:" + orderByCount );

  65:     Console.WriteLine( "OrderBy then Where" );

  66:     whereCount = 0;

  67:     orderByCount = 0;

  68:     composite

  69:         .OrderBy( test =>

  70:             {

  71:                 orderByCount++;

  72:                 return test.Date;

  73:             } )

  74:         .Where( test =>

  75:             {

  76:                 whereCount++;

  77:                 return test.Date >= DateTime.Today.AddMonths( 5 );

  78:             } )

  79:         .First();

  80:     Console.WriteLine( "    Where:" + whereCount );

  81:     Console.WriteLine( "    OrderBy:" + orderByCount );

  82: }

Here are the results:

IEnumerable<Anonymous> : Comparing Anonymous.Date

Compare <= 
Where then OrderBy
    Where:20
    OrderBy:5
OrderBy then Where
    Where:1
    OrderBy:20

Compare >= 
Where then OrderBy
    Where:20
    OrderBy:16
OrderBy then Where
    Where:5
    OrderBy:20

What causes this phenomenon?  The use of IEnumerable and yield expressions.

A few things to consider when building query expressions:

• What are the relative efficiencies of the Where and OrderBy algorithms?
• Does the Where yield a relatively large result (as a percentage of the original data)?
  • Is the question above difficult to answer because of the dynamic nature of your data?
• Would using negative logic change the result?
  • <= versus >
  • OrderBy versus OrderByDescending
• Are the Where and OrderBy predicates related?
  • e.g.  You may filter by Status but order by Id

I received quite a bit of feedback regarding my Join extension to IEnumerable that generates a comma separated list.  The purpose was to emulate string.Join(), but to add more flexibility as to what is "joined".

I took some time aside to investigate some of the suggestions and alternatives to my implementation.  I should note, that I would not normally do this.  I try to avoid premature optimization.  However, there are certain practices that can be learned that improve performance in general (like using a StringBuilder).  With these in your toolbelt, you can build better performing applications the first time, and at little or no cost.  It takes no more effort to use a StringBuilder than to concatenate strings in a loop (at least once you become familiar with StringBuilder).  Regardless, the intent of this post is not to try to sell you on StringBuilder.

Consider the fact that many optimizations involve tricks or algorithms that could make the intent of the method less obvious.  Unless you really need that optimization, are you really willing to pay the price?  Most of us do not work on applications that require lightning fast code.  In my career, the only times that I have had to address performance in my C# code was when I was working with bulk import and export of data.  In those cases, I was dealing with hundreds of thousands if not millions of iterations of my code.  In this case, a millisecond here or there can make a big difference.  On the other hand, saving a couple of milliseconds to pull up an ASP.Net page is hardly worth the effort.

The bottom line is, your customers will feel the effects of broken code before they recognize a couple of milliseconds added to their page load times.  In other words, don't sacrifice readability and maintainability for run-time optimization (unless you absolutely have to - even then, get a second opinion).

In response to a comment on one of my previous posts (Safely Overriding Equals), I've decided to post some comments about Extension methods in general.

A friend asked me what I gained out of extending string to convert to an enum.  He asked, "is it just 'syntactic sugar'?"  The simple answer is, "Yes."  In fact, this is true of many extensions.

Clearly, the major advantage of extensions is changing the syntax of how they are called.  In fact, I have written a few extensions that support chaining and make my code more readable (at least in my mind)

   1: OracleCommand command = GetProcedureCommand( "fas_closing_pkg.GetClosingDealLegs" )

   2:     .WithInputParameter( "pClosingMonth", closingMonth )

   3:     .WithInputParameter( "pDealId", dealId )

   4:     .WithOutputCursor( "oDealLegs" );

So what are extensions?  Well, they are just static utility methods with an extra keyword.  You can even call the extensions as if they are static methods if you really want to.

For Example:

   1: left.SafeEquals( right, test => left.Key == test.Key );

   2: GeneralExtensions.SafeEquals( left, right, test => left.Key == test.Key );

The second line is no different than what you might have written in .Net 2.0.  You may have even written many of these static utilties before and are now enabling them as extensions.

What this means, is that extensions are just static methods behind the scenes.  They are not instance methods.  One implication of this fact is that you must consider that the extended object could be null.  And, if it is null, you will not get an object reference exception when the extension is called.  You could get an exception within the scope of the extension method depending on your implementation.

For example, this is totally legal (generating no runtime errors)

   1: TestClass left = null; 

   2: TestClass right = new TestClass( "right" ); 

   3: Assert.IsFalse( left.SafeEquals<TestClass>( right, test => left.Key == test.Key ) );

Where SafeEquals is implemented as follows:

   1: public static bool SafeEquals<T>( this T left, object right, Predicate<T> test )

   2: {

   3:     if( left != null && right != null && right.GetType().Equals( left.GetType() ) )

   4:     {

   5:         return test( (T)right );

   6:     }

   7:     return false;

   8: }

So, when writing extensions, take a little extra time considering what would happen if the target object is null.