Dissecting and Putting the Visual Studio 2005 Generated Data Access Layer Into Perspective
Do more with less code is the slogan of Visual Studio 2005. When it comes to reducing the amount of written code, wizards are definitely a viable option. Visual Studio 2005 has a lot of wizardry in it, especially to generate data access code. Any code that gets silently injected in your project follows a strict logic and a well-known design pattern. A full understanding how Visual Studio 2005 does it puts you on the right track to modify and extend the code to build your made-to-measure data access layer. This article dissects the code behind table adapters and binding source components to unveil patterns and best practices.
One of the most popular selling points that Microsoft has pushed since the launch of the .NET Framework 2.0, Visual Studio 2005, and ASP.NET 2.0, is that you need to write much less code, and often no code at all. No code for what? For software applications? Is this the age of intelligent programming and talking machines, where you talk to computers and they magically understand and behave consequently? No. No such rocket science lives here as yet. Thankfully.
For more information on data access design patterns, you might want to take a look at “Patterns of Enterprise Application Architecture,” by Martin Fowler, published by Addison-Wesley Professional.
More simply, the “no-code-at-all” slogan refers to the cumbersome presence of zillions of wizards, add-ins and add-ons, and designers that you interactively program through drag-and-drop, check boxes, and buttons. You “declare” what you want and Microsoft’s tools produce code that does what they think you asked for. You may remember the slogan that made history for programming-what you see is what you get (WYSIWYG)-to introduce rapid-application development tools like Visual Basic. I think you could call the new slogan “what-you-get-is-what-the-tool-thinks-you-want” (an impossible to pronounce, WYGIWTTTYW).
With the 2005 series of products and technologies, Microsoft offers mere mortals tools to do good multi-tier programming. And what’s the essence and quintessence of multi-tier programming if not a serious, well-architected middle-tier?
I seem to hear a sounding voice rising from the back of the audience. Hey, wait a moment. Are you perhaps thinking that Microsoft is committed to (finally) teach developers principles and patterns of object-oriented design (OOD) and programming (OOP)? My answer is, sort of. Or, at least, not explicitly.
As a matter of fact, in Visual Studio 2005 you find a bunch of Windows Forms and ASP.NET data controls designed to connect to middle-tier objects and create data-driven applications quickly and quite effectively. Admittedly, this is great news no matter the perspective from which you look at it.
By using the newest Visual Studio 2005 data designer, you create code through user-driven wizards. However, the code you get after clicking the Finish button contains much more abstraction than in previous versions of Visual Studio. You work with top-level objects such as table adapters and typed datasets, but in the end you get a thin, but much better than nothing, middle-tier. More importantly, though, you have the option of connecting this top-level API to your own data access layer thus completing a canonical multi-tiered system.
In any case, you should quit with the tons of ADO.NET free-form code that many developers relentlessly inserted in code-behind ASP.NET pages and Windows Forms events. You’ve always been told to use layer separation, data transfer patterns, and effective data representation. But Visual Studio offered datasets and auto-generated ADO.NET code. Finally, today Visual Studio 2005 offers datasets and custom objects and auto-generates a largely customizable abstraction layer. What’s better, though, is that there’s method in this wizard. And you can recognize popular data access design patterns under the covers.
In this article I’ll examine and discuss the code generated by the Visual Studio 2005 data designer from an object-oriented design perspective.
By: Leonardo Esposito
Dino Esposito is the author of “Programming ASP.NET MVC” for Microsoft Press as well as “Programming ASP.NET 4” and other bestselling books such as “Microsoft ® .NET: Architecting Applications for the Enterprise”. Regular contributor to MSDN Magazine and DevProConnections Magazine, Dino is a frequent speaker at industry events all over the world including Microsoft TechED and DevConnections. After a decade of Web development, Dino jumped on the mobile bandwagon and is actively developing for iOs, Android and WP7.
Visual Studio 2005 allows you to pick a data source such as database, existing DAL or Web service and then returns an auto-generated set of classes to wrap it up. In particular, if you opt for the database option, you get a complete DAL designed according to a popular design pattern-Table Data Gateway-but hidden under new top-level object such as table adapters and XSD-driven DataSet controls. Once you fully understand it, you can edit and extend the code at will to make it work connected or disconnected, use commands or stored procedures, transactions, and validation.