Back Draft
Declaratively Speaking
Software development is on a trajectory toward fewer lines of code.
By Jonathan Goodyear
In one of my favorite presentations to give at conferences and user group meetings, I start by recounting how awful it used to be to integrate dynamic graphics and charts into Web applications with classic ASP. I contrast that with the GDI+ library implemented in the .NET Framework. The classes in the GDI+ library let you construct graphics dynamically on the fly (see Bill Wagner's article, Display Dynamic Images). By the time I've run through several demonstrations of how to build various different types of charts, audience members are usually pretty amazed at how much power and flexibility the GDI+ library offers.
That's when I introduce a third-party charting control/component by Dundas Software (http://www.dundas.com/index.aspx?section=ChartHome&body=body.htm). Why? Because even though you can build dynamic charts from scratch on your own, it still makes sense to let a component do the heavy lifting for you. It is much more intuitive to tell a component what to do declaratively rather than dig into the plumbing yourself.
This sets me up to show some of the true power of .NET. I use the charting component to build a complex chart that would take hundreds (perhaps thousands) of lines of GDI+ code. Then, I use the GDI+ library to apply customizations to simulate a specific business need (for example, overlaying a JPG picture, cropping, or thumbnailing). With .NET, I have the best of both worlds. I can use a component to build 90 percent of what I want declaratively. Then I can use built-in .NET functionality to apply customizations I need - customizations that might otherwise prevent me from using the component in the first place.
Software development is on a trajectory toward fewer lines of code. The next generation of the .NET Framework will continue this trend, introducing many new controls to help reduce the amount of code you need to write yourself. Instead, you'll place a control that performs a specific purpose on the design surface in Visual Studio .NET, then assign properties to make the control perform its task the way you want it to.
As with the charting component example, sometimes a declarative model simply isn't good enough. Component authors can realistically implement only so many properties, and they can realistically foresee only so many uses. The key to making the declarative model work effectively is .NET's interoperability as well as inheritance.
Most developers think of inheritance only from a business-logic component perspective, but inheritance also plays a big part in the visual aspect of development. As the declarative method of software development takes hold, it will become more and more important for third-party vendors (as well as Microsoft) to keep inheritance in mind when building visual controls and components (for both ASP.NET and Windows Forms .NET). When a developer encounters a situation that can't be handled adequately by an existing control, inheriting from an existing base control and extending its functionality makes more sense, rather than building a custom control from scratch. A lot of the productivity gains from .NET come from using what's there instead of rolling it yourself.
The day when software development is completely declarative is still years away, but in the relatively near future, our custom code will be reduced more to "glue logic" that binds together larger parts of our Web applications, whose implementations are abstracted away from us. And that's not a bad thing if we can control the action from the outside to suit our development needs.
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.
