仓酷云

标题: ASP.NET教程之从 ADO“典范”迁徙到 ADO.NET [打印本页]
作者: 小女巫    时间: 2015-1-16 22:32
标题: ASP.NET教程之从 ADO“典范”迁徙到 ADO.NET
说句实话，Java跨平台根本就不是外行人想想的那种，一次编译，处处运行。ado本文摘自HitchhikersGuidetoVisualStudioandSQLServer2005(7thEdition)
WilliamVaughn
BetaVCorporation
合用于
MicrosoftADO.NET
MicrosoftSQLServer2005（代号“Yukon”）
MicrosoftVisualStudio2005（代号“Whidbey”）
择要：BillVaughn会商了VisualBasic6.0ADO代码的转换历程，转换后的代码可以用于.NET使用程序以实行大抵不异的操纵。
作者申明客岁此时，Microsoft约请我撰写一篇文章，目标是匡助基于COM的ADO开辟职员了解将数据会见代码移植到.NET的机制和成绩。往年，他们但愿我更新这篇文章，并在个中到场有关ADO2.0的信息。因为今朝我正忙于HitchhikersGuide一书的新版事情，因而仅摘录新章片断，以飨读者。HitchhikersGuidetoVisualStudioandSQLServer2005(7thEdition)将在Whidbey和Yukon公布后由AddisonWesley出书刊行。
感激Calvin、Hobbes和BillWaterson。一段工夫以来，我一向入神于术语“变形”。此项手艺（明显）已风行一时，并且据称用于形貌田鸡变王子或木偶酿成人（反之亦然）的历程。可是，本文利用的变形是指VisualBasic6.0ADO代码的转换历程，转换后的代码可以用于.NET使用程序以实行大抵不异的操纵。变形意味着转换了局只能依据原始来历识别―在这类情形下，假定您将基于COM的ADO代码（从VisualBasic6.0）转换为ADO.NET是完整得当的。不外，一些人以为这类情形产生的大概性不年夜，对此我不敢苟同，谨以本文追根究底。
为何必要举行迁徙？

一个天色明朗的下战书，我在屋后的草坪上修睦了三速自行车，父亲提示我不该该修缮没有破坏的零件。我举双手同意。除非有心甘情愿的缘故原由必要修正功效性代码，而且在之行进行了公道的本钱-收益剖析，不然如许做毫偶然义。用“公道”这个词的意义是，不以兜销情绪的勾引（这类勾引大概来自于您的首席程序员，也大概来自于您夫妇的亲戚）为转移、同时思索到各类用度的周全剖析，这些用度包含计划、开辟、测试、部署和撑持使用程序，和对开辟职员、撑持团队和客户的从头培训的付出。为了运转该框架和新的使用程序，您大概还必要举行硬件晋级，这笔用度也是要思索的要素之一。尽人皆知，转换代码大概哪怕只是调剂一下，开支也是很高贵的。即便您不寒而栗，每行变动的代码仍是大概带来严峻的成果和反作用（只管一般是偶然的）。只管云云，仍是存在转换现有代码的充分公道缘故原由，比方：
•大概现有代码没法使用硬件或OS方面的改善。比方，大概代码是计划为与（并且大概仅与）Windows9x一同事情，而客户已晋级到WindowsXP。
•大概现有代码的合作力不如其他公司编写的代码，后者的使用程序速率更快、更牢靠，而且发卖份额更年夜。如许的事变频频产生，由于客户老是力图在功效、特征、和有合作力的代价方面坚持抢先。
•大概新的使用程序伸缩性更好、可以撑持更多的用户、更平安、更容易于部署，大概轻松完成了现有手艺所不具有的功效。
•大概客户埋怨代码仿佛事情一段工夫后就会逝世机―出格是在安装了其他一些软件以后。
•大概（大概最主要的是）您发明新的开辟平台可以进步创立新使用程序，撑持代码和利用该平台的小范围用户的才能。
我不盘算探求从现有代码基向新手艺的诱人远景行进的决议历程。我将它留给您的IT职员。假如您浏览本文的目标是为了把握转换基于COM的现有ADO代码（我称其为“ADO典范”或ADOc）的机制，以使其在VisualBasic.NET使用程序中运转，那末请持续。
我们是怎样走到这一步的？

Microsoft引进的数据会见接口历经了年复一年的更迭。后来，这些接口是为了会见特定版本的毗连性引擎手艺（JointEngineTechnology，JET）DBMS和SQLServer（经由过程DB-Library）而专门计划的。跟着这项手艺的不休成熟，其他“承继”接口或通用型（one-size-fits-all，OSFA）接口（如ODBC和OLEDB）生来就能够会见几近一切的数据源。创立基于COM的ADO（我称其为ADOc）是为了便利会见OLEDB。
ADO“典范”的进演
工夫流转，ADOc不休开展而且厥后来的8个版本也普遍使用，并集成到基于COM的VisualBasic中。ADOc开辟职员也学会了怎样构建办理各类范围数据库的使用程序，并将其使用到天下各地的客户端/服务器、两头层和ASP系统架构中。ADOc还撑持存储历程（包含完全的IO参数办理）、主动的UPDATE查询天生、异步操纵、客户端和服务器端游标、RO/FO数据流等，因而为人们所广泛承受。可是，基于COM的ADO还存在一些成绩。它对MDAC仓库的依附使其简单产生DLLHell成绩―偶然，部署的使用程序在晋级MDAC时会失利。
引进ADO.NET
为懂得决必需交换服务使用程序组件的成绩，Microsoft制造了.NETFramework。除此以外，Microsoft还创立了一个全新的数据会见接口―ADO.NET。在制造ADO.NET历程早期，Microsoft开辟职员将新的数据会见接口称为“XDO”。这是因为这个新的数据会见典范是经由过程XML置进接口的，因而它可以读取XML文件以添补其工具，大概依据必要延长XML以将数据和架构传送到其他层。因而，这个名字意义深入。但是，Microsoft以为假如创立另外一个数据会见接口，开辟职员将手足无措，乃至愤怒不休，以是将其定名为“ADO.NET”。固然，ADOc和ADO.NET在更高条理上的功效不异。不外，这二者在背景的事情道理一模一样，并且依我看来，年夜部分都是很杰出的。
ADO.NET初次面世时，短少良多如今看来成熟的ADOc所撑持的基础功效。这些基础功效包含：批文件更新、异步操纵、服务器端游标、运转时操纵命令天生等。有些人以为，ADO.NET是为了用于ASP.NET而计划的，客户端/服务器使用程序没有需要利用它，可是Microsoft深信断开毗连的DataSet可以使客户端/服务器使用程序更高效，并使其离开对难以扩大的计划（这些计划依附于服务器端形态办理）的依附。恰是因为该逻辑，ADO.NET不包括对服务器端游标的撑持。这个新思绪的中心是“断开毗连的”客户端数据存储，您能够依据必要轻松地将其保存并序列化为XML，以便传送到其他层。它也十分合用于Microsoft的新XMLWebServices―面向服务的系统布局(SOA)企图。注重，用于保存ADOcRecordset的XML与ADO.NET预期的XML格局不兼容。（请参阅MuchADOAboutData:DoingtheImpossible(Again)。）Microsoft还以为，最好同意开辟职员构建本人的SQL操纵命令（UPDATE、INSERT、DELETE）或经由过程导游构建，而不是依附属性驱动的ADOcUpdate办法代码，由于在实验弄分明怎样变动Recordset时，该代码常常堕落。固然，在一些复杂的情形下，这些代码也可以完成CommandBuilder以主动构建操纵命令，可是正如本文所述，我以为您不会接纳这类办法。（请参阅WeaningDevelopersfromtheCommandBuilder。）切实其实，这些成绩不是没有办理的办法，可是分外的开支会进一步拦阻人们举行迁徙，大概使迁徙历程难上加难。
办理疑问
另外一方面，Microsoft同意开辟职员编写托管接口，间接办理了有关OSFA的成绩。即ADO.NET公然了一个公用于MicrosoftSQLServer(SqlClient)和其他数据库（包含Oracle和DB2）的.NET数据供应程序。这意味着，数据供应程序引擎可以使用DBMS的一切功效，并以最低的级别与数据库通信。自DBLibrary以来，ADO.NET第一次可以经由过程表格数据流(TDS)―它是初级协定，与SQLServer举行交互。这意味着，SqlClient供应程序可以会见一切SQLServer功效，并懂得这些功效之间的渺小不同，从而使使用程序也就为虎傅翼。关于开辟职员而言，不存在将一种DBMS代码转换为另外一种代码的成绩，由于当地接口与OleDb和Odbc.NET数据供应程序完成的.NETOSFA接口相似。
ADO.NET还公然DBLibrary的另外一个功效―间接会见初级数据接口前往的数据流。这个接口在创建毗连时以只进、一次一行的体例将您的代码链接到查询前往的输出数据，它作为DataReader完成。ADO.NET中的一切办法都利用DataReader间接或在背景猎取了局集。这意味着，使用程序可以更快地猎取数据并更好地把持这个历程。
迁徙ADO典范代码的开辟技能

在很年夜水平上，年夜多半使用程序中的数据会见逻辑都能够分为几个部分：
•取得毗连：这触及到机关毗连字符串、（在某些情形下）集成用户供应的凭证，和创建毗连―及时或在操纵周期内。
•办理查询：这意味着创立查询字符串和集成用户供应的参数，还包含办理事件。
•实行查询：这包含选择与前往的了局集相婚配的得当实行办法。偶然是教唆用可吸收行汇合、标量、流或只是实行操纵命令的办法。
•办理（多个）了局集：这些例程存储和处置行汇合、前往的参数，或将了局绑定到控件。在处置条理布局数据时，这些例程大概还会办理前往行汇合之间的干系。在某些计划中，它们不仅能够经由过程客户端或服务器真个游标举行定位，还能够排序、选择或定位行。
•办理变动：当数据产生变动时，这些例程会将数据从静态源或绑定的控件挪动到ADO数据布局中，以经由过程ADO数据布局办理更新、拔出和删除操纵。这些例程还办理并发抵触、批处置操纵和事件。
•办理非常：一切这些例程都有非常处置程序，卖力处置在创建毗连、筹办并实行查询或将数据分发到服务器时呈现的罕见成绩。
ADO开辟职员将发明，他们可以以相似的体例分化和编写ADO.NET代码。可是，每部分都有不同，后来这有点使人懊丧，不外，只需独自处置就可以够轻车熟路。VisualBasic6.0转换导游其实不会将ADOc代码转化为ADO.NET―这是痴人说梦，由于ADO.NET接纳的编程办法与ADOc分歧。比方，假如利用ADOc中的SHAPE语法来办理条理布局，您会发明.NETFramework不撑持SHAPE，可是却撑持经由过程DataSet类办理多个相干的行汇合，一个DataSet类能够包括多个DataTable工具，每一个DataTable工具包括一个自力的行汇合。
每一个.NET数据供应程序都卖力完成切合本人“作风”的ADO.NET类。它们都撑持一组利用（大抵）不异的属性和设置的“中心”操纵。固然，每一个.NET数据供应程序还撑持各自的SQL变体和ConnectionString设置。比方，SqlClient供应程序（用于MicrosoftSQLServer）可完成SqlConnection、SqlCommand、SqlDataAdapter和SqlDataReader，而OleDb供应程序还撑持OleDbConnection、OleDbCommand等。在我撰写的书本中，这些工具是依据功效来援用的―比方，SqlCommand就称为“命令”类。
ADO.NETConnection(SqlConnection)类与ADOcConnection工具相似，可是它承受一个分歧（但熟习）的ConnectionString。它不克不及以异步体例开启，可是在实行Fill和Update办法时，它可以由DataAdapter主动办理。在ADO.NET中，不克不及间接针对Connection工具实行SQL―必要构建一条命令来完成这项操纵。您还要修正毗连毛病处置程序，以使其意料到在实验ADOc毗连时产生的统一类成绩。请注重，ADOc利用的毗连池机制与ADO.NET大抵不异，可是经由过程ADO.NET办理池选项和形态更简单。
ADO.NETCommand类与ADOcCommand工具相似，可是在这类情形下，必需构建一个Command工具来实行SQL或运转存储历程。ADO.NETCommand工具公然的办法与ADOc的办法有大相径庭。与ADOc分歧，您能够会见一个新的初级接口―DataReader(SqlDataReader)，该接口公然一个高速原始数据流，用于前往查询数据。Command类撑持的Parameters汇合与ADOc中利用的Parameters汇合相似。请注重，ADO.NET中的SQL参数标志体例有所分歧。
您还会发明，ADO.NETDataTable与ADOcRecordset大抵等效。固然它不是作为游标举行办理，可是经由过程它存储和办理前往的行汇合更无效。定位到特定行与数组寻址一样简单。经由过程DataSet，还能够一次办理来自分歧数据源的多个行汇合。这个类用于办理一个或多个DataTable工具和这些工具包括的行汇合。您可以编写这些行汇合（即便它们来自分离的源）之间的干系代码，和依据您界说的父子干系轻松地举行定位、选择和搜刮。
数据绑定也产生了变更。不必研讨VisualBasic6.0数据绑定的繁文缛节，只需在代码中利用拖放天生的代码或设置数据绑定链接，您就可以够更轻松地绑定到行汇合。ADO.NET2.0对数据绑定典范的不断改进使得这个历程加倍复杂。
对ADOcRecordset举行寻址的开支很年夜，由于一切列都是作为Variant前往的。ADO.NET可以使用强范例的DataTable和DataSet，因而举行工具寻址是小菜一碟。这意味着，数据以原始范例存储和办理―即，整数存储为整型，字符串存储为字符串。您大概还会注重到，强范例操纵是更快的指令。我们还勉励您在开辟情况中利用“OptionStrictOn”和“OptionExplicitOn”选项。固然这意味着代码必需显式强迫变量（经由过程代码转换范例），但失掉的代码将更不乱，以便在乎外数据抵达时不会像平常一样失利。
为了使办理表格更新更轻松，ADO.NETDataAdapter仿照了VisualBasic6.0数据工具导游(DOW)。这个类同意界说本人的UPDATE、INSERT和DELETESQL―一个特别的SQL查询或存储历程。这使得ADO.NET加倍轻便，可是代码要承当天生这些命令的义务―ADO.NET不再像ADOc那样在运转时实验天生这些命令。前面我们将看到，ADO.NET2.0从头引进了批文件更新和异步操纵来提拔功能。
与ADOc一样，非常处置也是ADO.NET计划的一个主要部分。侥幸的是，.NETFramework撑持Try/Catch非常办理，与您熟习的传统VisualBasic6.0“OnError”例程比拟，它的功效更壮大并且更天真。这类非常办理办法同意您将那些以数据为中央的特定非常从其他成绩招致的非常中选择出来。这使编写非常处置程序更复杂，并使使用程序不测失利的大概性更小。
ADO.NET2.0有哪些新功效？

ADO.NET2.0的最新版本弥补了一些迁徙ADOc时遗留的空缺，并完成了一些不足为奇的功效。这些立异同意您天生更平安、更强健、速率更快的代码―出格是Windows窗体（客户端/服务器）使用程序。这些晋级包含：
•没有MDAC依附。ADO.NET的初期版本一般请求晋级MDAC仓库（包含运转ADOc使用程序所需的DLL），而ADO.NET2.0在利用SqlClient时停止了这类依附性。MDAC的初期版本(2.6-2.9)可以满意OleDb和Odbc.NET数据供应程序。这意味着，安装.NET使用程序的损坏性较小，由于它不会影响现有的ADOc使用程序。
•异步操纵。固然ADO.NET2.0不克不及像ADOc那样以异步体例翻开毗连，可是它可以异步地实行DataReader命令。这意味着，您可以编写代码，以便在实行查询时代为用户出现一个进度条，大概在使用程序线程上实行其他事情，并依据进度前往形态事务。
•多举动了局集(MARS)。在ADO2.0之前，我们不克不及利用一个毗连实行多个操纵。可是MARS能够在统一个毗连上撑持多个操纵。这意味着，在同时读取和更新行时，不用翻开多个毗连。固然，这要假定.NET数据供应程序和方针DBMS撑持这个功效。
•批处置。ADOc撑持在一个往复路程中将多个操纵命令发送到服务器的功效。这个功效在ADO.NET2.0中从头完成了。经由过程批实行Update办法操纵，使用程序的变动速率更快，而且与服务器之间的往复路程更少（更便宜）。
•BCP撑持。在将数据移出内部数据源或天生的数据源时，利用批量复制有用工具(BCP)取代传统的ADO.NET办法很主要。ADO.NET2.0如今包括一个BCP类，以同意间接会见这个高速的数据上载功效。在传统ADO办法所需的一部分工夫内，这类办法就能够完成批量数据传输。
•将DataSet公然为DataReader。为了使在层与层之间公然数据更便利，如今能够创立一个DataSet（或DataTable），并将该数据集作为DataReader传送到另外一个层。您也能够间接从DataReader加载DataTable。
•DataSet序列化。在初期版本中，可使用Remoting在各层之间传送DataSet，可是数据是以XML格局传送的。在ADO.NET2.0中，能够将DataSet序列化为二进制格局。这意味着层间功能的急剧增加，可是要利用Microsoft的公用格局来传输数据。另外一个选项(SchemaSerializationMode=TypedDataSet)可以往除数据流中的架构，从而削减传输的数据量，同时仍旧合用于跨平台的情形。
•Yukon撑持。ADO.NET2.0初次能够撑持当地SQLServer2000数据范例，还大概撑持基于CLR的用户界说范例。这些数据范例包含varchar(max)、nvarchar(max)、varbinary(max)和新的XML范例。
•新的大众基类。为更轻松地编写通用使用程序，ADO.NET2.0公然了一个DB*基类。比方，公然DbConnection、DbCommand和DbDataAdapter。这些类仍旧请求利用特定于供应程序的SQL语法，可是经由过程它们能够编写出可以会见多个分歧数据源的使用程序。
•服务器和供应程序列举。这些新类同意您探究.NET数据供应程序供应的功效，和使用程序可见的服务器和实例。在编写办理工具、启动/中断/停息服务器或只是断定服务器形态时，这些类十分有效。请注重，除SQL-DMO，SQLServer如今还公然了SMO来办理SQLServer实例。
•新的计数器。SqlClient供应程序在.NET的初期版本中公然了很多计数器，可是它们都不太牢靠。这些新的计数器将更准确，而且可以断定毗连池机制的形态。
•毗连池办理。ADO.NET2.0不仅同意您扫除一个或一切的池，并且还同意扫除办理池举动的其他功效，而初期版本仅同意您选择毗连池选项。改善的毗连池机制还能匡助您检测坏池―毗连到不成用服务器的池。
Whidbey集成
ADO集成到VisualBasic和VisualStudio已有一段工夫了。可是，VisualStudio2005团队此次在集成级别长进展地加倍深切了一些。固然不会看到创立熟习的DataAdapter的导游，可是您将看到拖放手艺，它们能够天生很多熟习的和新的强范例数据布局。请记着，当您但愿RAD接口天生代码时（出格是在复杂的情形下），这些工具最风趣。Microsoft宣称他们还为撑持N层开辟做了大批事情。您能够创立在统一个程序集内天生DataSet的使用程序，也能够创立在援用的程序会合会见数据集和本人的工具的使用程序。当计划变得较庞大时，这些工具能够公然您本人天生的两头层营业工具。有关该集成的会商超越了本文的局限，可是在我的书本中将触及到这一点。
替换计划是甚么？

关于任何一种软件办理计划来讲，都有一打替换办理计划―在完成一个办理计划后，老是有人可以就每处指出一打替换办法。固然，每种办法都各有益弊。本文，我们将重点会商数据会见接口的成绩，并将其他的转换义务留给其别人。固然，您的数据会见代码也许没那末简单断绝。固然迄今为止，年夜多半业界学者和我自己已议论3层（或“N”层）计划几十年了，但并非每一个人都采取我们的倡议。假如您创立的使用程序带有一组处置数据的自力两头层工具，那末转换这些工具以撑持ADO.NET的义务将十分复杂。可是，假如您的代码琐屑不胜，就像我多年以来检察的“意年夜利面条”代码，那末要将ADOc例程从使用程序的布局中扫除而不使使用程序分崩离析，您大概会履历一段备受煎熬的历程―就比如在初春时节里，一边与俄罗斯狼犬搏斗，一边试着拔失落它身上的狗毛。上面我们看一下替换办法―个中必定有一种办法对您和您的技能有匡助。
•经由过程VisualBasic6.0导进项目导游将您的项目转换为ADO.NET项目。听说新的VisualStudio2005转换导游比以往的导游加倍智能，可是它仍旧不克不及将ADOc代码转换为ADO.NET。固然在较年夜且较为庞大的项目中使用它大概还必要一段工夫，可是关于较复杂的项目而言，完成转换应当是好事多磨的。转换后，您将失掉变更并包装在COMinterop层中的ADOc代码，以便它可以在新的VisualBasic.NET项目中编译，并（与注册后的MDAC版本一同）部署和运转在方针体系上。这还意味着，您必要注重编码技能（有一些早期绑定技能变形效果不太好），我在客岁这个时分撰写的那篇文章中会商过这些技能。
•另外一个可行的办法是会见每一个ADOc代码区段，并按逻辑将其分化。想像一下，假如经由过程一个断开毗连的DataSet就可以完成义务，大概义务仅利用DataReader来前往行―这相似于默许的“消防栓”Recordset。在这类情形下，转换到ADO.NET是一种既复杂又洁净的历程。在处置服务器端游标（在客户端/服务器使用程序中出格罕见）时，您必要决意从头计划代码以利用断开毗连的DataSet的战略，大概思索利用ANSICURSOR操纵符办理本人创立的服务器端游标类。在良多情形下，举行一些计划上的变动会打消对服务器端游标的必要。可是，这大概不切合实践情形，因而请深思熟虑。
•假如您在两头层组件平分离了ADOc代码，那末第三种办法将出格有效。在这类情形下，“只需”创立前往相似布局的组件的ADO.NET版本便可交换ADOc代码―假定组件利用者不将ADOcRecordset前往到其他层。假如您公然一个自界说营业工具类，则经由过程VisualStudio2005中的工具将其变形为基于ADO.NET的数据会见组件将轻而易举。
次要思索事项
在大马金刀地展开转换历程之前，您必要思索动手点，并扣问以下成绩：“我可以克制一切困难险阻来完成转换吗？”请思索以下影响转换历程的要素：
•您从哪一种范例的系统布局举行迁徙？假如从ASP编程系统迁徙，则ASP.NET办法将非常壮大，而且办理ADO工具的体例也一模一样。您会喜好这类新办法，固然在此之前它还不克不及处置双向数据绑定，可是如今能够了。
•您的妙技怎样？您最善于哪一种盘算机言语？假如您编写过很多VisualBasic6.0代码，而且像良多人一样利用VisualBasic.NET有一段工夫了，那末“按逻辑”移植代码对您来讲大概更简单。这就是变更操纵，而不是代码自己。只需不利用服务器端游标，您就可以够使用年夜多半毗连字符串和SQL。假如您的妙技今朝还没有到达这个程度，那末实验从利用VisualStudio2005迁徙导游入手下手大概会更简单，这是由于年夜多半复杂情形下举行的转换都不难。
•您的代码在多年夜水平上依附于服务器端功效，比方，键集、静态游标或办理服务器端形态的例程（如#temp表）？在这类情形下，转换历程将更坚苦，由于即便是最新的ADO.NET2.0也不间接撑持该功效。可是，有一个替换举措―利用ANSICURSOR命令。（请参阅我的文章利用ANSICURSOR语句）。
•您是从ADO典范（ADOc1.0至2.6版）、DAO、ODBC仍是其他某个公用数据会见接口举行迁徙？从对照新的ADO版本举行迁徙要简单很多，由于良多观点是类似的―不是不异，而是类似。假如利用VisualBasic6.0迁徙导游，则无需修改便可移植年夜部分ADOc代码。固然，这会呈现一些成绩，我在之前的文章中提到过。
•可是，从DAO、ODBCAPI或公用接口举行迁徙倒是另外一回事。主动化导游大概基本不克不及转换您的代码，乃至连实验一下都不可。假如是如许，我倡议您从头剖析DBMS引擎。假如先利用DAO，然后又利用JET，我一般倡议客户从JET迁徙到SQLExpress，由于它更壮大、更不乱而且具有更高的可扩大性。Microsoft正在尽量疾速地周全交换JET，我倡议客户和先生也尽快交换。
•您利用的绑定控件是甚么？只管某些复杂控件（如TextBox、ListBox和ComboBox）的转换路径相称复杂，但DataGrid却不是。VisualBasic.NET中的绑定机制从基本长进行了改善并具有严重差别，因而在迁徙庞大的绑定控件时，您大概会发明一些不联贯的中央。很多属性在.NET等效控件中纷歧样了，并且一些办法也没有了。第三方控件一般以.NET版本供应―您大概但愿在冒险利用这些控件之前先查询拜访一下。至于自界说控件，VisualStudio2005转换这些控件的效果更好，可是您不要希冀太高―我嫌疑这个转换导游的新增功效会呈现良多成绩。
•您筹办编写本人的SQL操纵命令逻辑吗？别忘了，ADO典范在运转时会依据SELECT语句为您创立该SQL。相反，ADO.NET则勉励您本人编写这些操纵命令的代码。如前所述，您可使用CommandBuilder并很快舍弃其范围性。我以为您将发明它不像ADO典范的Update办法那样天真―出格是思索到UpdateCriteria属性同意您变动所创立的操纵命令的范例时更是云云。
小结

是的，ADO“典范”代码能够变成ADO.NET。完成历程像看起来那样难吗？我对此置疑。一旦了解ADO.NET是一个全新（且更好）的数据会见接口而不是ADOc，您就会对转换历程更中意。并非一切的使用程序都必要转换。我后面说过，假如零件没坏就不必要修缮。我但愿这对您有所匡助。假如您必要更多匡助，这里有几本书可以派上用处。不管怎样，我但愿本文可以助您落井下石。
相干书本
ADO.NETandADOExamplesandBestPracticesforVBProgrammers
ADO.NETExamplesandBestPracticesforC#Programmers
1.变形(tràns-mòg
作者: 柔情似水    时间: 2015-1-18 16:16
是指转换后的Servlet程序代码的行数。这给调试代码带来一定困难。所以，在排除错误时，可以采取分段排除的方法（在可能出错的代码前后输出一些字符串，用字符串是否被输出来确定代码段从哪里开始出错）。
作者: 飘飘悠悠    时间: 2015-1-31 06:09
当然我们在选择Asp.net主机是，除了要考虑服务提供商在版本是否是实时更新以外，机房的环境和配置也是非常重要的，通常选择骨干网的机房，在速度和稳定性上会非常有保证。
作者: 活着的死人    时间: 2015-2-6 17:46
现在主流的网站开发语言无外乎asp、php、asp.net、jsp等。
作者: 再现理想    时间: 2015-2-17 20:57
JSP/Servlet虽然在国内目前的应用并不广泛，但是其前途不可限量。
作者: 乐观    时间: 2015-3-5 22:44
ASP.net的服务器，要求安装一个.net环境，当然我这里指的是windows系统，顺便点一下，.net只能放在windows环境里来运行。Asp.net1.1的就装Framework1.1，Asp.net2.0的就装Framework2.0。
作者: 飘灵儿    时间: 2015-3-12 16:34
代码逻辑混乱，难于管理：由于ASP是脚本语言混合html编程，所以你很难看清代码的逻辑关系，并且随着程序的复杂性增加，使得代码的管理十分困难，甚至超出一个程序员所能达到的管理能力，从而造成出错或这样那样的问题。
作者: 愤怒的大鸟    时间: 2015-3-20 00:03
ASP.NET:ASP.net是Microsoft.net的一部分，作为战略产品，不仅仅是ActiveServerPage(ASP)的下一个版本；它还提供了一个统一的Web开发模型，其中包括开发人员生成企业级Web应用程序所需的各种服务。ASP.NET的语法在很大程度上与ASP兼容，同时它还提供一种新的编程模型和结构，可生成伸缩性和稳定性更好的应用程序，并提供更好的安全保护。



欢迎光临 仓酷云 (http://ckuyun.com/) Powered by Discuz! X3.2