The .NET Architect
By Jonathan Goodyear
When I was younger, one of my favorite toys was LEGOs. I loved how you could use them to build any number of different toys to play with. As fun as LEGOs were, they could also be very frustrating. Often, I would have to disassemble part or all of one of my toys if I found that I had built something wrong and I needed to change my approach to the problem.
After a couple of years I was able to build LEGO toys much more easily. Aside from the expected increase in maturity that normally accompanies two birthdays, I had made one additional (yet very important) discovery: The instruction manual. As it turns out, there is some pretty useful information in there. I could follow the step-by-step blueprints in the instruction manual to build the toy pictured on any box of LEGOs that I was given.
A couple of years ago, I was given the .NET Framework to play with. I like to call it "LEGOs for adults," because you can use the thousands of .NET Framework classes to snap together working applications faster than ever before. My LEGO experience reminds me that I can still build my objective faster and with fewer mistakes if I have an instruction manual and some diagrams to work from. Unfortunately, most of my clients don't feel the same way. It is excruciatingly painful for them to throw money at a development process for several weeks and not see any code being generated. "Just code," they tell me.
Some clients have just enough software development knowledge to be dangerous. They say things like, "buy components." Components are small units of encapsulated code (such as a grid control, file compression library, or report generator) that take care of a specific purpose for you. They don't do much good in a vacuum, though. Components are like leaves on a tree. Put a bunch of them together and all you get is a pile of leaves. You need a framework to attach them to.
"Use a pattern" is what usually comes out of my clients' mouth next. "Duh" is the response that I want to give ... but I (usually) think better of it. Patterns are oft misunderstood, though. Put simply, patterns are merely generic solution frameworks for common application architectures. Microsoft has an entire Web site dedicated to demonstrating common pattern implementations in .NET (http://www.microsoft.com/resources/practices/), but at the end of the day, patterns are still only the trunk of your tree. Every application needs one, but if "Model-View-Controller" alone could solve everyone's problems, then I wouldn't have a job.
The missing link here (as if my analogy hasn't already given it away) is the branches. Branches represent the business logic that makes each and every application unique. When you talk about designing an application, you pick the pattern that makes the most sense and the components that you feel will save you some development time, but the business logic is what needs to be modeled.
The benefits of modeling the business logic of a system before starting to build it are pretty profound. For starters, you get entities that more closely resemble their real-life counterparts. You also get a blueprint of system interactions that can be picked up by anybody on your development team. New hires can become instantly productive. You don't make as many mistakes that require (potentially very costly) backtracking and refactoring. I don't have enough room here to outline all the benefits of modeling, but you get the idea.
The obvious tool to model your application's business logic is the Unified Modeling Language (UML). It's the industry standard (http://www.uml.org), and can be extended to meet any specific needs that you have. This column isn't meant to be an advertisement for any particular UML product, although there are plenty of good ones out there; just Google "UML" to start looking for one that meets your requirements and budget. So get modeling - and buy your clients a box of LEGOs so they can play along.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, Fla. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angrycoder.com/.