宾馆客房管理系统外文毕业论文.doc

宾馆客房管理系统外文毕业论文Architectural Overview of ADO.NETThe ADO.NET object model consists of two fundamental components: the DataSet, which is disconnected from the data source and doesnt need to know where the data it h-olds came from; and the .NET data provider. The .NET data providers allow us to conn-ect to the data source, and to execute SQL commands against it.NET Data ProvidersAt the time of writing, there are three .NET data providers available: for SQL Server, for OLE DB data sources, and for ODBC-compliant data sources. Each provider exists in a namespace within the System.Data namespace, and consists of a number of classes. W-ell look at each of these providers shortly.Data Provider ComponentsEach .NET data provider consists of four main components: Connection used to connect to the data source Command used to execute a command against the data source and retrieve a DataReader or DataSet, or to execute an INSERT, UPDATE, or DELETE command against the data source DataReader a forward-only, read-only connected resultset DataAdapter used to populate a DataSet with data from the data source, and to up-date the data sourceNote that these components are implemented separately by the .NET providers; ther-e isnt a single Connection class, for example. Instead, the SQL Server and OLE DB pro-viders implement SqlConnection and OleDbConnection classes respectively. These class-es derive directly from System.ComponentModel.Component there isnt an abstract Co-nnection class but they implement the same IDbConnection interface (in the System.D-ata namespace).The Connection ClassesThe connection classes are very similar to the ADO Connection object, and like that, they are used to represent a connection to a specific data source. The connection classes store the information that ADO.NET needs to connect to a data source in the form of a f-amiliar connection string (just as in ADO). The IDbConnection interfaces ConnectionS-tring property holds information such as the username and password of the user, the name and location of the data source to connect to, and so on. In addition, the connection class-es also have methods for opening and closing connections, and for beginning a transactio-n, and properties for setting the timeout period of the connection and for returning the cu-rrent state (open or closed) of the connection. Well see how to open connections to speci-fic data sources in the section on the existing .NET providers.The DataReaderThe DataReader is ADO.NETs answer to the connected recordset in ADO.However, the DataReader is forward only and read-only we cant navigate through it at random, and we cant use it to update the data source. It therefore allows extremely fast access to data that we just want to iterate through once, and it is recommended to use the DataRe-ader (rather than the DataSet) wherever possible. A DataReader can only be returned fr-om a call to the ExecuteReader method of a command object; we cant instantiate it dire-ctly. This forces us to instantiate a command object explicitly, unlike in ADO, where we could retrieve a Recordset object without ever explicitly creating a Command object. Th-is makes the ADO.NET object model more transparent than the flat hierarchy of ADO.The DataAdapterThe last main component of the .NET data provider is the DataAdapter. The DataA-dapter acts as a bridge between the disconnected DataSet and the data source. It exposes two interfaces; the first of these, IDataAdapter, defines methods for populating a DataSet with data from the data source, and for updating the data source with changes made to the DataSet on the client. The second interface, IDbDataAdapter, defines four properties, ea-ch of type IDbCommand. These properties each set or return a command object specify-ing the command to be executed when the data source is to be queried or updated. Note that an error will be generated if we attempt to update a data source and the correct com-mand hasnt been specified. For example, if we try to call Update for a DataSet where a new row has been added, and dont specify an InsertCommand for the DataAdapter, we will get this error message: Unhandled Exception: System.InvalidOperationException. Update requires a valid InsertCommand when passed DataRow collection with new rows.Well look briefly at how we avoid this error when we discuss the DataSet.Existing Data ProvidersThree .NET data providers are currently available; these allow us to access any type of data source that we could access using ADO 2.1. The reason weve said ADO 2.1 rat-her than 2.5 (or later) is that the OLE DB 2.5 interfaces IRow, IStream, etc. (exposed by the ADO Record and Stream objects) are not supported by the OleDb provider. This means that well still need to use classic ADO with data sources such as web directories and the Exchange 2000 Web Store, until such time as ADO.NET equivalents for the Int-ernet Publishing (MSDAIPP) and Exchange 2000 (ExOLEDB) OLE DB providers bec-ome available.The SqlClient ProviderThe SqlClient provider ships with ADO.NET and resides in the System.Data.Sql-Client namespace.It can (and should) be used to access SQL Server 7.0 or later databases, or MSDE databases. The SqlClient provider cant be used with SQL Server 6.5 or earlier databases, so you will need to use the OleDb .NET provider with the OLE DB provider for SQL Server (SQLOLEDB) if you want to access an earlier version of SQL Server. However, if you can use the SqlClient provider, it is strongly recommended that you do so using the OleDb provider adds an extra layer to your data access code, and uses COM interoperability behind the scenes (OLE DB is COM-based).The classes within the SqlClient provider all begin with Sql, so the connection class is SqlConnection, the command class is SqlCommand, and so on.The OleDb ProviderIf youre not using SQL Server 7.0 or later, its almost certain that your best bet will be to use the OleDb provider, at least until more .NET providers are released. There are a couple of exceptions to this rule if your data source has an ODBC driver, but not an O-LE DB provider, then you will need to use the Odbc .NET provider. Support for MSDA-SQL (the OLE DB provider for ODBC drivers) was withdrawn from the OleDb provider somewhere between Beta 1 and Beta 2 of the .NET Framework, so there really is no al-ternative to this. This was probably done to prevent the use of ODBC Data Source Names (DSN) with ADO.NET, except where ODBC really is required. Even in ADO, using D-SN involved a substantial performance penalty (particularly when an OLE DB provider was available), but the extra layers would be intolerable under .NET. Think of the arch-itecture involved: ADO.NET COM interop (optional) OLE DB services OLE DB provider ODBC driver data source!The second situation where the OleDb provider doesnt help us has already been mentioned. If you need to access a data source using the Exchange 2000 or Internet Publishing Provider (IPP).The OleDb provider acts much like traditional ADO it is essentially just a .NET wrapper around OLE DB(except that the OLE DB service providers are now largely obsolete, as this functionality and more is provided by ADO.NET). So as well as specifying that were going to use the OleDb .NET provider (by instantiating the Ole-DbConnection etc. objects), we need to specify the OLE DB data provider that we want to use to connect from OLE DB to the data source. We do this in the same way as in ADO by including the Provider property in the connection string, or by setting the Pro-vider property of the OleDbConnection object.Like the SqlClient provider, the OleDb provider resides in System.Data.dll, and ships with the .NET Framework. The classes that compose the provider are in the Sys-tem.Data.OleDb namespace, and all have the prefix OleDb (OleDbConnection, OleDb-Command, and so on).The Odbc ProviderThe Odbc provider should be used whenever you need to access a data source with no OLE DB provider (such as PostgreSQL or older databases such as Paradox or dBase), or if you need to use an ODBC driver for functionality that isnt available with the OLE DB provider. Architecturally, the Odbc provider is similar to the OleDb provider it acts as a .NET wrapper around the ODBC API, and allows ADO.NET to access a data source through an ODBC driver. The Odbc provider classes reside in the System.Data.Odbc na-mespace, and begin with the prefix Odbc.The DataSetThe other major component of ADO.NET is the DataSet; this corresponds very rou-ghly to the ADO recordset. It differs, however, in two important respects. The first of th-ese is that the DataSet is always disconnected, and as a consequence doesnt care where the data comes from the DataSet can be used in exactly the same way to manipulate data from a traditional data source or from an XML document. In order to connect a Da-taSet to a data source, we need to use the DataAdapter as an intermediary between theDataSet and the .NET data provider.ADO.NET and XMLPerhaps the single most impressive new feature of ADO.NET is its built-in support for XML. In fact, XML is now the standard persistence format for ADO.NET DataSets. While weve been able to save recordsets in XML format since ADO 2.1, the default format remained the proprietary Advanced Data TableGram (ADTG) format, and XML support was always limited. We couldnt, for example, load an arbitrary XML document into an ADO recordset the document had to be in exactly the right format. XML supp-ort in ADO.NET is far more complete XML is absolutely integral to ADO.NET, and not just an add-on. XML is the format used to serialize and transport DataSets.Serializing a DataSet as an XML document (to a file, a stream, or a TextWriter object) is a trivial matter. The format of the generated XML document is far more readable than the ADO equivalent the columns are represented by elements, not attributes, and there arent a lot of unnecessary XML namespaces. In addition, we can load any well-formed XML docu-ment into a DataSet, without having to use a predefined structure (although we might lose content if the structure of the document is not basically tabular).ADO.NET体系结构ADO.NET对象模型由两个基本组件组成：一个是数据集（DataSet），它与数据源断开并且不需要知道所保持数据的来源：另一个是.NET数据提供者（.NETdata provider），.NET数据提供者能够与数据源连接，并执行针对数据源的SQL命令。1.NET数据提供者在本书编写时，有三种可用的.NET数据提供者：SQL Server数据提供者、OLE DB数据源提供者以及和ODBC兼容的数据源提供者。每个提供者都位于system.Data命名空间内的一个命名空间中，并且由许多类构成。我们将简述这些提供者。(1)数据提供者组件每个NET数据提供者，都由如下四个主要组件构成。 Connection用于连接到数据源 Command用于执行针对数据源的命令并且检索DataReader或者DahSet，或者用于执行针对数据源的一个INSERT、UPDATE或者DELETE命令 DataReader既个己连接的、前向只读结果集。 DataAdapter-用于从数据源产生一个DataSet，并且更新数据源.注意，这些组件由.NET提供者独立实现：例如，没有单一的Connecdon类。但SQL Server和0LE DB提供者分别实现了SqtConnection和0leDbConnection类。这些类由System.ComponentModel.Conponent直接派生而来（不是一种Connection抽象类），但是他们在systemDate命名空间中实现了相同的IDbConnection接口。Connection类.Connection类与ADO Connection对象类似都用于表示到某特定数据源的连接。Connection类存储了特定信息，ADONET需要利用这些信息以常规连接串的形式连接到数据源(与ADO一样)。IDConnection接口的ConectionString属性保存了诸如用户名、用户密码、数据源连接名称和位置等信息。另外，connection类还具有打开和关闭连接、启动事务以及设置连接超时时间和返回连接当前状态(开放或关闭)等属性。在“已有的NET提供者”一节，我们将考察如何打开到特定数据源的连接。 Command类与ADO Command对象相似，Command类提供了IDbCommand接口它们用来执行SQL语句或数据源中的存储过程。另外，类似于ADO Command 对象， Command 类包含CommandText和 CommandType 属性， 其中CommandText属件包含了执行数据源的命令文本，而commandType属性表明命令是否是SQL语句并且包含存储过程的名称或数据表名称。该类还包含三个不向的执行方法返回DaReader的ExecuteReader、返回单值的ExecuteScalar以及在查询数据时不返回数据的ExecuteNoquery(例如，SQL UPDSTE语句)。类似于ADO的Conmmand对象，Command类包含Parameters类集个对象集合，用于表示传递到存储过程的各个参数，这些对象提供IDataParameter接口并且构成部分NET提供者。也就是说，每个提供者都独立实现IdataParameter和IdataParameterCollection接口。 DataReaderDataReader在ADONET中的作用，类似于ADO中的己连接记录集。但是，DataReader是前向、只读的不能随机地访问它，也不能用它来更新数据源。因此，它可以快速访问那些只需次循环遍历的数据，而且提倡在这种情况下尽量使用DataReader(而不用DataSet). DataReader只能从Command对象的ExcuteReader方法调用中返回，不能直接对其进行实例化。这使得需要显式地实例化一个Command对象，这与ADO.NET不同，在ADONET中无需显式创建Command对象便可获取RecordSet对象。这使得ADONET对象模型比ADO的平面层次结构更透明。 DataAdapterNET数据提供者的最后一个主要组件是DataAdapter。DataAdapter是断开的DataSet和数据源之间的桥梁。它提供两个接口：一个是DataAdapter，用于定义根据数据源中的数据产生DataSet对象和通过改变客户端的Dataset来更新数据源的各个方法；第二个接口是IDbDataAdapter,定义了每种类型IDbCommand的四个属性。在查询或更新数据源时，每个属性都设置或返回指定执行命令的Command对象。注意，如果试图更新数据源但是没有指定正确的命令，就会产生错误。例如，如果对已加入新行的Dahset调用update却不为DataAdapter指定InserCommand，将会得到如下的错误消息。 不能处理的异常：Sysgtem.Invalid OperationException。当传递带有新行的 DataRow集时，更新操作需要一个有效的InsertCommand命令。在讨论DataSet时，我们将简单介绍如何避免这种错误。(2)已有的数据提供者现在有三种可用的NET数据提供考：这些数据提供者使得我们可以访问任何用ADO 21能访问的数据源。使用AD0 21而不是25(或更新版本)的原因是：OLE DB数据提供者不支持OLE DB25的IRow、IStream等接口(分别由ADO的Record和Stream对象提供)。这意味着仍存在需要使用传统ADO的数据源(例如Web目录和Exchange 2000 web Store)，这种情况会持续到Intermet Publishing(MSDAIPP)和Exchange 2000(EX0LEDB)OLE DB提供考的同类ADONET产品问世。SqIClient提供者SqlClient提供者与ADO.NET捆绑销售，属于SystemDatasq1client命名空间。它能够而且也应该用来访问SQL Server 7O或其更新版本的数据库，也可以访问MSDE数据库。sqlclient提供者不能在SQL Server 65或更早版本的数据库上使用，因此如果要访问SQLserver的早期版本，就要使用0IeDbNRY提供者和SQL Server的0LE DB提供者(SQLOLEDB)。但是，如果可以使用SqlClient提供者，就应该尽量使用它使用0LEDB提供者会在数据访问代码中引入一个附加层，并且需要利用COM的互操作性(OLE DB是基于COM的)。SqlClient提供者中的类全部以“Sql”开头，所以Connection类为SqlConnect，Command类为SqlCommand，以此类推。 OleDb提供者 如果不是使用SQL Server7.0或更新版本，最好使用OleDb提供者，至少在发布了更多的NET提供者以前是这样的。关于这条规则有许多例外情况如果数据源包含0DBC驱动程序接门，但没有OLEDB提供者，就需要使Odbc.NET提供者。在NET框架的B1版本向B2版本过渡期间，OleDb提供者对MSDASQL的支持(用于0DBC驱动程序的OLEDB提供者)被删除了，因此在这一点上没有其他的选择。这样做可