RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Putting the VS 2005-Generated Data Access Layer Into Perspective

Get an insider view of VS 2005 auto-generated Data Access Layers (DALs) so you can edit and extend the code.

o 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.

Author's Note: For more information on data access design patterns, you might want to take a look at Martin Fowler's book "Patterns of Enterprise Application Architecture," 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, but 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.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date