When I Was Your Age...
By Jonathan Goodyear
We ve all heard the phrase, usually spoken by our parents or grandparents and usually when we re taking advantage of a modern convenience that wasn t available when they were younger. They feel compelled to tell us how tough things were when they were our age, and how lazy we are now that technology has made things easier for us. There are certainly older programmers among us who tend to be curmudgeons when it comes to some of the new programming techniques being used today. I have to resist this myself all the time. But are such attitudes valid in some cases?
Whenever a new programming technology is released, it abstracts away the details of what is going on under the hood. The obvious advantage is that programmers can get more work done in less time. The tradeoff is that there is an inherent loss of control over the underlying implementation. Consequently, many programmers never bother to learn the details of what the new technology is abstracting away from them, making it exponentially harder for them to diagnose problems that arise out of that technology s use. Joel Spolsky coined the term The Law of Leaky Abstractions to define this concept (http://joelonsoftware.com/articles/LeakyAbstractions.html).
One of the main points that Spolsky makes in his essay is that programming abstractions are designed to make work more productive for programmers who already know how the underlying technologies work. The truth of the matter is that programming abstractions are usually used to commoditize programming and bring it to the masses of people who have absolutely no idea what is happening under the covers. I will admit that were it not for the grand programming abstraction known as Visual Basic, I (an accounting major in college) would never have gotten the opportunity to enter this incredible career field.
I realized early on that I had a lot to learn and have done my best to fill in the gaps of my knowledge, but it is hard for anyone to keep up with the intricate details of every technology that comes our way. So, the larger questions become, which abstractions are good enough to use now, which will eventually be good enough (through our friend, the service pack), and which ones may never be good enough. Also, is a technology sometimes a good alternative, and sometimes not?
The concept of Object Relational Mappers (ORM) springs to mind as an abstraction concept that is under intense debate lately. Several ORM tools, such as LLBLGen and SubSonic, have been out for awhile. They usually provide a one-to-one mapping between database entities (tables, views, etc.) and programming objects in your favorite .NET language. More recently, Microsoft has released LINQ to SQL, and will be following up in a few months with LINQ to Entities. LINQ to SQL is very similar to the other ORM technologies that I mentioned, but adds several language enhancements that make its implementation even more powerful. LINQ to Entities goes one step further by allowing the developer to define the mappings between objects and multiple database entities (or vice-versa).
Both LINQ to SQL and LINQ to Entities, however, still suffer from the limitation that you have little to no control over the T-SQL that these abstractions generate to actually interact with the database. If you hook up SQL Server Profiler and look at some of the queries that are being executed against your database, you may be horrified at what you see. Many industry experts are skeptical about whether ORM technology can scale to enterprise systems, and recommend the tried-and-true approach of using vanilla ADO.NET to call database stored procedures.
I used to be in that camp, but after using various ORM technologies over the past couple of years, I now take a middle-of-the-road approach. I agree that some of the most demanding enterprise applications cannot afford any performance degradation, and require their database interactions to be tweaked to exact specifications. However, I think that many of the naysayers miss the point that ORM technology can be safely applied to more than 90% of the software applications being built today. Most of them are Line of Business (LOB) applications that won t feel the load of thousands of concurrent users, or have to deal with terabytes of data. They are being built by average programmers who are looking for any possible advantage to help them meet their deadlines.
Truth be told (and don t take this the wrong way), most programmers in this industry would fare much worse performance-wise if they attempted to do everything manually. That is why we buy third-party components from trusted vendors who are experts in their particular technology niche. This allows the average programmer to accomplish tasks that simply would not have otherwise been possible. One thing I would definitely recommend, though, is that each programming team have one or two senior programmers (or access to them via consulting or other means) who are good at debugging, in order to get your project over the hump when you run into one of the leaks in the abstractions that you choose to implement. You don t want to give back all the time you initially saved by spinning your wheels. I also recommend using abstractions that have been out for awhile, so there are fewer leaks to be plugged.
I d like to close out this month s BackDraft by giving a shout out to a software product that I use that is worth checking out. PureChat, by Axosoft, allows you to directly interact with the customers that visit your Web site. It s inexpensive, carries no ongoing fees, and I implemented it on my company s Web site in less than 30 minutes (http://purechat.com).
Jonathan Goodyear is president of ASPSOFT (http:// www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, an ASP.NET MVP, a Microsoft Certified Solution Developer (MCSD), and co-author of ASP.NET 2.0 MVP Hacks (Wrox). 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.