Karl’s back with part 4 of the series. Today we learn all about the evils of coupling and we’re introduced to Dependency Injection – the slayer of improper coupling.  Proper use of DI allows for cleaner separation of responsibilities which, in turn, creates more resilient and less brittle code. Most importantly it makes unit testing much easier.  You are writing unit tests for your code, aren’t you?

Share this post: digg it | Email it |


Part 3 of Karl Seguin’s Foundations of Programming series is now online. This time it’s all about persistence, mapping between object graphs and relational databases (O/R Mapping), and impedance mismatch.  Read, learn, and never again get bogged down in stored procedure-based hell!

Share this post: digg it | Email it |

Microsoft MVP Karl Seguin is in the middle of a multipart series named Foundations of Programming. If you are a professional .NET developer, you need to know this stuff.  While DataSets and DataGrids are great tools for relatively simple tasks, they just aren’t robust enough to carry forward into the world of enterprise development. The Object Oriented fundamentals in part 1 and the Domain Driven Design method explored in part 2 are tried and true solutions that many Java, Smalltalk, and other OO developers have been refining for years. The upcoming articles in the series are sure to introduce many more important concepts that have only recently begun to gain traction in the .NET world.

Go give it a read.  I promise that if you take the time to truly understand the topics Karl covers, you will be a much better developer as a result.  That’s my money-back guarantee!

Share this post: digg it | Email it |

I just stumbled across an open source web development project called PageMethods. This clever yet simple to use library eliminates the need to hardcode, parse, and generate URLs and QueryStrings in a web application.  Instead, PageMethods replaces them with strongly typed objects that allow compile time checking and all the other intuitive benefits of a managed code language.  (This falls under the “why didn’t I think of that” category!)

I’ve been working in .NET 1.1 the past few weeks and this morning I figured out a simple solution to a problem that may not even exist anymore in later versions (I try to stay away from UI work so I’m a bit behind in that area). I created a custom business object that exposes several properties as primitives (string, bool, etc.). What a pleasant surprise to find that binding my object to a DataGrid required nothing more than setting the grid’s DataSource equal to an instance of my object. No different than binding to a DataSet, which I’ve done many times.

Enter the problem: one of the properties in my object exposes a Collection, and the DataGrid doesn’t know how or what to display in that column. After flailing around in Google for an hour, I found a clue in my own code: in the column that is mapped to the collection was the fully-qualified name of the Collection class. Extrapolating from this that the DataGrid is probably calling ToString() on each field to display its contents, I overrode my collection’s ToString() method and iterated the internal collection to build up the output string. And what do you know, sure enough, the data I wanted to see in that column automagically appeared with a recompile and a simple browser refresh.

Granted – this is far from the perfect generic solution for this problem. There is no way to modify the output’s format short of parsing and reassembling it (nasty!). But in following the YAGNI principle I know this can be fixed up later with relatively little pain if it becomes necessary.

This morning at the NAB convention in Las Vegas, Microsoft announced that the Windows Presentation Foundation Extensions product has been renamed Silverlight. It’s a good thing because WPF/E doesn’t exactly roll off the tongue.

Inspired by my recent visit to Las Vegas, I’m planning on writing a simple slot machine emulator for practice and perhaps even for a CodeProject article/tutorial. It will be a good chance to finally learn Silverlight.

Jeff Atwood rants about OOP for OOP’s sake here. If you don’t feel like reading it, the main theme is for developers to focus on Programming For Others rather than simply on Object Oriented Programming. In other words: don’t write objects for objects’ sake.

One of my recent contracts required me to do some cleanup and debugging work on an enterprise-level product life cycle management site. There wasn’t a class in the entire suite of applications that didn’t extend and implement at least an abstract base class and an interface. Many implemented 4 or 5 interfaces, in fact. I’m sure it was elegant to the developers who designed it but it was a nightmare to comprehend.