Is This Book Written For You?

I'm often asked if my books are a good match for the skills and interests, and needs and focus of one group of developers or another. While I would like to say, "It's for anyone who can read," that's not really true, as you might expect. I can say the book is for:

Software developers, architects , and their managers who specify, design, code, assemble, test, deploy, support, update, and live with business applications that manage dataespecially SQL Server data.
Developers with some experience in Visual Basic 6.0, Visual Basic .NET, or C#; or those developers skilled in other languages who want to understand these languages and how to use them to create data access applications.
Anyone who wants to leverage the latest and ever-evolving Visual Studio and SQL Server feature setlearning what works, what doesn't, and why.
Consultants and mentors who want to learn how to best support their SQL Server customers by creating quick applications more quickly.
Those who want to try to learn how to best use SQL Server for the first time, as well as those who have experience with SQL Server and its versions and variations.
Any of the previously mentioned people who wants to know how and (more importantly) when to leverage the power and potential of SQL Server 2005 CLR executables or SQL Server Reporting Services through the new Report Viewer control.
Students, teachers , trainers , and courseware designers who want to gain or pass on useful skills to be competitive in the software-development business.
It's written so I can simply point to a place where anyone anywhere on the planet can get another point of view on how to develop data access applications using Visual Studio and SQL Server.
It's also written for me. It's my way of passing on what I've learned by experience and from my readers, my session attendees, and those folks whose questions I've answered over the years .
It's also for Alberta Lee, my 81-year-old mother-in-law, as she puts a copy of the book on the mantel to show her friends .

Getting Help and Support

Look for links to my EBooks on the seventh edition's support website: www.hitchhikerguides.net. A six-month paid subscription to this site is included with the price of this book. All I ask is that you register with the site using the "scratch-and-sniff" number found just inside the front cover of the book. This, along with a valid email address, will permit you to gain access to the "premium content" area that includes updates, errata, and reduced-cost access to my growing number of EBook offerings, as well as the ability to participate in the reader's forum section of the site. I encourage you to use the site to provide feedback, ideas for other content, and support for other readers. I hope this helps.

William R. Vaughn

President, Beta V Corporation

Chapter 1. Exploring Application Architectures

Introduction

Choosing the "Right" Architecture

Understanding Your Toolset

Recognizing Application Design Constraints

Choosing the Right Data Access Interface

Choosing the Right Database Management System

Understanding Basic Data Access Architectures

Summary

Introduction

A professor at MIT is quoted as saying, "Design is what you do when you don't [yet] know what you are doing." ^[1] This is very trueeven for application architects . It seems that so many of us depend on the wisdom of others to design their systems that we fail to learn the fundamentals of system design. As a result, the end product can scale, run efficiently , and be maintained for decades to comecome what may.

^[1] George Stiny, Professor of Architecture, Massachusetts Institute of Technology, 21 June 2002.

IMHO

"Too many of the designs I see lack the solid foundations needed to have them last beyond the next strong wind." ^[2]

^[2] William Vaughn, President of Beta V Corporation, 22 July 2006.

Before getting started on a tour of Visual Studio and SQL Server 2005, I feel a need to lay some groundwork . In my previous books ^[3] , it was assumed that the reader had a firm understanding of how SQL Server works, knew how to write T-SQL, and knew how to build a normalized relational database. Since then, I've seen too many questions that could be simply answered by a better understanding of those fundamental tenants. To make it easier for you to understand why one architecture or technique is suggested over another, let's start by providing some foundational material that should help make your choice of architecture and how you build your applications easier. Of course, if you think that you're up to speed on all of these issues, feel free to skip on down.