I Object
In a recent issue (“Am I a Mad Scientist?” CoDe Magazine, May/June 2005), I wrote about the obvious practical benefits of creating strongly-typed classes within a custom software application. Since then, I’ve been thinking more about the not-so-obvious benefits of object-oriented design (OOD), which seem to be worth discussing as well because they appear to be rooted in a better way to develop software. The first article centered on the benefits mainly of strong typing; this one focuses more on the benefits of, if you’ll allow, true OOD. By “true object-oriented design” I mean object-driven design; that is, basing your software solution domain on the actual problem domain as opposed to, say, data-driven design, which is by far the more common design approach within Microsoft circles. I think this point doesn’t bear much proving in this article, as it is patently obvious by the artifacts existing today in the form of marketing, presentations, tutorials, the majority of Microsoft-related articles, developer tools, and indeed in the many millions of applications existing today that are clearly the result of data-driven (i.e., starting with the data and how it will be stored and reported upon) design. But for those who want some evidence, consider two things, one of which I’ll discuss in more depth in this article. First, consider the popular code generation tool, CodeSmith, and other generation tools like it. These tools require you to have developed your database first and will happily create code for you to access and persist the data within it. Sure, you can generate custom classes using these tools, but you have to start with the database and design it in such a way as to be usable by the tools to generate their code. The second evidence is found in the DataSet itself. One need only consider the vast numbers of articles, presentations, and tutorials written about it and the unequaled support that the tools such as Visual Studio and the Microsoft GUI frameworks (WinForms and ASP.NET) have for it. I’ll get more into this later. Object-driven design, on the other hand, starts with the problems that you are trying to solve. Not only does it start with the real world, but it asks you to consider the objects in the real world, specifically the behaviors that define them and make them unique and pertinent to the problem at hand. It then takes that knowledge and applies it, creating a solution of objects based on these, a solution that better addresses the problems because it acts in ways that naturally make sense. There isn’t time to fully develop this concept here, so I direct you to Dr. David West’s recent book, Object Thinking (MS Press, 2004), to further explore object-driven design (object thinking). Most objections to creating custom classes and using OOD revolve around ease of use or, rather, ease of design and implementation. There seems to be, strangely enough, almost unanimous agreement that custom classes ala OOD are better if you have time. The argument is that data-driven design ala the DataSet (and its predecessors like the RecordSet) is easier because it has better built-in tool support and is generic enough to represent most data. Even the argument from developer experience (i.e., that inexperienced developers can’t do object-driven custom class design) boils down to the fact that Microsoft has made it much easier and more common to use the DataSet than custom classes. But does that make it right? Microsoft has gone to considerable lengths to create a fully-featured, strongly-typed, and object-based platform for developers (called the .NET Framework, in case that’s not clear). While it is still maturing, it is an impressive and fun platform to develop on (from a professional developer’s perspective) that challenges any of the alternatives as the best platform for general-purpose software development and is almost certainly the best platform for business-oriented solutions. Microsoft also has a superlative RDBMS, SQL Server, and they, obviously, realize the importance of giving their application development platform access to their (and others’) data persistence platforms. They’ve got an entire System namespace for dealing with this aspect of development called System.Data, and that is precisely where the DataSet and its comrades live. (Henceforth, “DataSet” refers to DataSet and related System.Data classes.) In other words, DataSet is a tool to deal specifically with data persistence, which includes persistent data access. The problem is that Microsoft and friends have drastically expanded the purpose of DataSet, evolving it from being part of the data persistence framework into a one-size fits all solution to application problem domains, or at least that is the impression one gets based on the aforementioned artifacts. They do this by providing all these fancy GUI tools that make editing data (note, I don’t say “building an application”) easy. These tools work great for demonstrations to sell the platform; hence the marketing artifacts. These tools do not, however, build great applications-they simply build data editors with minimal constraint-like validation on the data. I’m talking about Access++, InfoPath++, Excel++, or just plain Office++. This is not software development; this is not even application building; it is simply a souped up way to edit and store data. If that’s all you need, just go with one of the these commercial products and don’t waste a ton of money investing in SQL Server, application servers, developers, development, project management, quality assurance, etc., to build a custom application. If, however, you need a piece of software that does something quasi-intelligent, such as automate business processes and solve (or help to solve) business problems, you’ll want to consider investing in .NET, SQL Server, Java, Oracle, app servers, developers, and so on. And if you are investing in that, you also want to make sure that your investment will have the highest return possible. In order to do that, you need to think about long-term things like scalability, extensibility, and maintainability. These things cannot be offered by the drag-n-drop experience advocated in Microsoft demos and fly-by-night consultants. They cannot, indeed, be offered by abusing the DataSet as a solution domain. Not only will such abuse negate key long-term returns on investment, it will also unnecessarily complicate the solution domain because you are trying to fit a square peg into a round whole, using a hammer as your only tool, and other such nifty and overused aphorisms. | & | | 
By: J. Ambrose Little Ambrose currently works as the Codemunicator for Infragistics, the leader in presentation layer components. He's contributed to two books, Professional ADO.NET 2 and ASP.NET 2 MVP Hacks, both by Wrox, and he speaks at local events and conferences when he can. You can reach him via email or his blog at http://dotNetTemplar.Net .
ambrose@infragistics.com |