Geeks With Blogs
Chris Falter .NET Design and Best Practices

I have been saved from many a peril during my adventure of a life.  A vision of Christ's compassion during my sophomore year in college saved me from the confusion of agnosticism.  An unexpected delay in our return to a Third World country (where my wife and I were serving in a Christian humanitarian organization) saved me from undergoing an emergency appendectomy in a decrepit, unsanitary hospital overseas.  Committing two bad blunders in the 2006 World Open chess tournament saved me from the temptations I would have faced from winning thousands of dollars.

When I was instrumenting our a web application's interfaces to external systems, I reflected on some of the design choices we had made.  We could have written a "data-driven" user interface with controls bound directly to OleDb data intrinsics, instead of to domain objects.  How would I then write instrumentation code?  Answer: I would have to re-write all the data binding code, perhaps by binding to newly coded properties (of type DataSet) on the code-behind pages, then inserting the instrumentation into the properties.  Ugly, time-consuming, and error-prone.  Yes, good design had saved our shop (and me) from what would have transpired if we had implemented the "Smart UI" anti-pattern in our enterprise software.

Well then, what if our data layer had consisted of dozens of individually coded data routines, rather than passing all requests through Microsoft's Data Access Application Block?  Perhaps I would not have experienced the Smart UI train wreck, but I would still have had to insert instrumentation code at dozens of points.  Not a happy prospect.

Instead, by inserting code into just 3 methods in the Data Application block, I was able to obtain a log of all stored procedures and their execution times.  Saved by good design!

And because we set up an internal "facade" web service to manage requests for GIS data from our vendor, and because inside that web service I had refactored the web methods so they all called a single method to handle the interaction between our system and the vendor's, logging the request document type, the timestamp, the elapsed time, and so forth required only a single line of code.  Saved again by good design!

Implementing good design is like getting timely oil changes for your vehicle.  In the short term it takes a little extra time and money--but eventually, it will pay for itself many times over. 

And it may very well save your code-slinging skin!  Good design certainly saved mine.

Posted on Tuesday, July 24, 2007 11:24 AM Coding Practices and Design Patterns | Back to top

Comments on this post: Saved By Good Design

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris Falter | Powered by: