"Never put off until run time what can be done at compile time."
David Gries, Compiler Construction for Digital Computers

Introduction

　　作为程序员，我们在学习一些新技术的时候，范例有时候会是我们最大的敌人。指南通常被设计成简单易懂，但同时里面的懒惰、无效率的甚至是危险的代码编写会增多。像这种情况最普遍存在的就是在ADO.NET的范例中了。在这篇文章中，我们将看一下数据库中的强类型对象有什么意义，会让你在你的程序中这样做，尽管缺乏范例。
　　有点特别的是，我们将看到在Visual Studio 2005中是如何创建和使用强类型数据集的。正如这篇文章所探究的，与另外一种弱类型数据存取技术相比，强类型数据集提供了许多有利之处。我们也会在这里看到，用Visual Studio 2005创建和使用强类型数据集并没有变得更简单。想学更多就继续看下去吧。

The Basics and Benefits of Strongly-Typed Objects

　　要想明白强类型是什么意思，你可以先想想约会。如果你是单身，你会考虑跟哪种类型的人约会呢？你可能有一些特定的标准（比如健康和有魅力），又或者标准很简单或并不是很明确。无论你的条件是什么，当你决定更多地与谁一起的时候，你总会用自己对这一些类型的一定的标准去衡量考虑。如果你很聪明，你会想一大堆来保护自己不受感情创伤。你可能会发现，比如说，与一个酒鬼相处是很不稳定，除非两人之间有一个认真的关系。但是，让一个人改变是很痛苦并且非常困难的。因此，你的智慧会指示你让你在这段关系开始前就叫停。给你的约会标准里加一个不喝酒的条款会保护你不会在未来心痛，并且让你可以更专心的把你的时间和精力放在更好的候选人身上。
　　你可能在惊讶这个推理与编程有什么关系。没关系，跟我来吧，可爱的读者！ADO.NET数据存取对象是被设计成极富弹性的。当你从数据库中读取数据时，你可能是用许多平常.NET framework允许的的通用类型的对象在工作，除非遇到特殊的问题。应用我们的约会理论，基本上可以把你的相关数据看作是通用对象。“我约会的只要不是太麻烦的就好了。”难道你就不能再明确一点吗？甚至连是人还是其它生物都没有限制！作为你的朋友，我恳求你，“多点标准吧！让你的清单缩小一点！”
　　正如你如果忽视约会的对象是谁会导致将来的关系问题一样，在你的代码中放任你的objects也会造成一些错误。并且，如果你让旧的object在你的子程序中漫舞，你可能直到程序运行执行时才会发现这是个问题。用我们的约会理论来看，在运行时捕捉错误就好像你的约会在一间新潮的意大利餐馆中间发生痛苦和难堪的争吵一样。是的，你发现了，如果你在之前先有计划，你就不会在一堆用餐者的注视中结束这个场面，也不会很难堪。只要在你的代码里简单地应用一些严格点的标准，你就可以在程序开始编译前捕捉到错误。比如下面这句代码例子：

string FirstName = myrow.("FirstName").ToString(); 　　
　　这个例子中的DataRow是无类型的，结果就是，你必须要用列的名字作字符串去得到你所需要的值（或者你可以选用这个列在记录的列集合中的索引）。好在那一列确实存在。DataRow的列的数据类型是object，我们假定这个FirstName列下面的数据类型是string，而且我们在使用之前必须要把它显式转换成string。如果这一列的名字发生变化（例如变成PersonFirstName），编译器并没有办法通知你。郁闷吧？但你可以不这样的。如果你的代码像下面这样，你的生活就会更简单，你的代码就会更可靠。

string FirstName = PersonRow.FirstName;

　　在这第二个例子中，我们用一个强类型的行，并且我们知道FirstName属性是string类型的。没有凌乱的列名，也没有乱七八糟的类型转换。编译器已经为我们做了类型检查，我们可以放心的进行其它工作，而丝毫不用担心是否把列名敲对了。
　　其它所有的东西都是一样的，所以你肯定会毫不犹豫地使用这种方式，而不再使用通用类型的方式。但请等一下，强类型objects是从哪里来的？我也希望我可以告诉你这些objects是自动创建的。但是，正如良好的关系需要时间和精力一样，让你的objects强类型也需要额外的努力。但花在这里的额外时间绝对是值得的，它也节省了在未来“捉臭虫”时花费的更多的指数级的时间。
　　完成强类型有好几种方法，我们将在这篇文章余下的部分介绍如何在Visual Studio 2005中创建强类型的数据集。我们也会把这种做法与其它做法的优缺点作一个比较。

Creating Strongly-Typed DataSets in Visual Studio 2005

　　强类型数据集其实只是把普通数据集的列和表预先定义好，所以编译器已经知道它们包含什么。取代你好像带着棒球手套弄的松散的包装，强类型数据集正像一个非常合适的手套。而Visual Studio的每一次连续的版本都使得数据集强类型化的处理更加简单。在下面这个例子中，我们将使用SQL Server 2005的AdventureWorks数据库。简单地执行下面一些步骤：
1. 打开Visual Studio，创建一个新的ASP.NET网站。
2. 在Solution Explorer窗口，右键点击新增一个项，选择DataSet。给其命名为AdventureWorks.xsd（见截图）。Visual Studio将推荐你把DataSet文件放进App_Code文件来，你只要点同意就可以了。
3. 打开AdventureWorks.xsd之后是设计模式，TableAdapter配置向导将会运行。这时候，点取消，我们将从Server Explorer中把所要的表拖进来。
4. 在Server Explorer工具栏中浏览找到AdventureWorks数据库。（如果你还没有安装AdventureWorks数据库，你可以去微软的下载页面SQL Server 2005 Samples and Sample Databases下载它和一些其它的SQL Server 2005示例）
5. 把SalesOrderHeader表和SalesOrderDetail表拖进DataSet的设计窗口。窗口应该会像截图中一样。我们看到的是什么呢？每当我们增加一个表，Visual Studio就会创建一个强类型DataTable（名字和原来的表一样）和一个TableAdapter。这个DataTable已经为我们定义好每一列。TableAdapter是我们用来填充表的，默认有一个Fill()方法从原表中得到每一行数据。

　　照原来的样子的话，这个强类型数据集将会返回这两个表的所有记录。但是AdventureWorks数据库包含了许多订单信息，因此为什么不创建一个更明确的查询呢？我们可以给TableAdapter对象增加方法来获取一个特定的子记录集。右键点击SalesORderHeaderTableAdapter，然后选择Add|Query。选择“Use SQL statements”后点下一步，然后选择“SELECT which returns rows”再点下一步。最近，在窗口中输入下面的查询语句（或者可以使用Query Builder来完成这项工作）：

SELECT
     SalesOrderID, RevisionNumber, OrderDate, DueDate, ShipDate,
     Status, OnlineOrderFlag, SalesOrderNumber, PurchaseOrderNumber,
     AccountNumber, CustomerID, ContactID, SalesPersonID, TerritoryID,
     BillToAddressID, ShipToAddressID, ShipMethodID, CreditCardID,
     CreditCardApprovalCode, CurrencyRateID, SubTotal, TaxAmt, Freight,
     TotalDue, Comment, rowguid, ModifiedDate

FROM Sales.SalesOrderHeader
WHERE (OrderDate > @OrderDate)
　　这个SQL查询是一个简单的SELECT查询，用了一个@OrderDate参数以筛选结果。这将使我们不用返回数据库中的所有记录。保持“Fill a DataTable”和“Return a Da