剖析 .Net 下的数据访问层技术（一）

l 弁言自从 .net 真实走入开拓职员那天起，“功效”两个字就从来变成稠密步调员津津有味的话题。不管是从开拓形式（cross language）、体例框架（.net framework），仍旧百般运用简单的东西（vs.net），无一不展现出了它的胜人一筹。同声，在另一上面，.net 能否不妨真实独当一面企业级运用（enterprise application）开拓的重担，却仍旧商量连接，指摘纷歧。常常来说，对于一个企业级运用，须要商量的上面很多，如安定、本能、舒卷性、易用性等。在正文中，作家更承诺与大师一道商量 .net 下数据考察层的关系本领，这大概是在多层框架结构（n-tier architecture）出生之日起就遭到普遍关心的敏锐话题，而对于大局部开拓职员来说，这也大概是名目中最让人懊丧的局部，甚或惹起争议最多的局部。在以次阐明中，为一致起见，作家姑且将数据考察层简称为dal（data access layer）。l 领会题目大略统计领会后，就不难创造，dal之以是让人畏缩，并非出于本领自己的题目，以至凑巧差异，很多开拓职员觉得这是最没有本领含量的局部之一（就作家体验的巨细名目来看，该层所占的开拓功夫普遍较短，也是很多开拓职员不承诺接受的“苦差”），不过框架结构须要大概某些思维破坏（如：为dal而dal）才介入了这所谓的第四层（保守三层框架结构并没有提出dal思维）。dal的提出，真实对保守的框架结构形式提出了宏大挑拨，介入的手段确定也是蓄意借其进一步普及消费功效，在这种形式下，理念情景是：大局部开拓职员此后解脱dba之苦，甚或完全中断与数据库的径直联系，sql之痛将离咱们而去，所有oo寰球此后宁静。然而，理念归理念，是否变成实际则需经过名目检查。接下来，作家试图领会比拟时髦且较有代办性的几种处置计划，看看是否居中得出少许有价格的论断，并为咱们此后在安排与实行dal时供给少许模仿。u ado.net开始，提到.net下的dal，连忙映入眼帘的即是ado.net。没错，简直一切的dal处置计划（请承诺作家运用solution而非framework）都必需从它兴盛而来，没得采用，这也是具备.net特性的实行办法（比拟较j2ee）。废除贸易成分及clr自己的须要，ado.net真实带给咱们的货色不多,犯得着一提的也就dataset（就作家体验的名目来说,运用更多的是datatable和dataview）。从微软早期的外存数据库（memory database）鲜有人问津到即日的dataset大行其道，这个中的委曲实非三言两语所能道尽，总之，有一点不妨确定，恰是有了dataset这种采用，.net下的dal本领象即日这般百花齐放，大师的思绪本领更趋宽大。duwamish这上面有很多好的sample，最典范的莫过于微软大举引荐的企业级开拓套餐：duwamish。对于蓄意进修.net下dal安排的伙伴，这是一个不错的开始，这上面的完备领会，大师不妨参考“csdn开拓能手，2003.11”，正文不复赘述。作家本人介入的一个名目中就运用了duwamish计划，其时限于工期，发觉这是一个很好的参考，没做深刻领会就发端安排了。此刻回顾起来，创造仍旧有很多不及之处。举个大略的例子，duwamish计划中并没有商量cache management，而这对于企业级运用来说，某些功夫即是一个不得不商量的题目；另一上面，固然duwamish中分别了sql语句（十足沿用保存进程实行），但数据库陈迹保持格外鲜明，比方：某些字段称呼的设置，关系表称呼的设置之类。再有一个格外头疼的题目是在开拓进程中展现出来的。一发端，那些比拟大略的数据表还比拟简单实行，到了少许包括彼此联系的数据表时，咱们的dal工程师就感触了压力，到厥后，简直又做了一遍dba在数据库建立模型时早已做过的处事，只然而，这次将数据库剧本换作了c# 实行（大概说：将数据库构造换成了外表上具备oo特性的dataset）罢了。大概，duwamish的实行比拟典范，但在本质运用中，偶尔并不表示着best practice。就拿咱们的名目来说，固然胜利托付，但不管从模子复用观点，仍旧开拓功效来说，都不许算很胜利。套用一句时髦语：本来咱们不妨做得更好！petshopado.net上另一个犯得着参考的dal实行即是赫赫有名的petshop。固然了，与duwamish一致，名望大偶然真的适用。petshop固然填补了duwamish在某些上面的不及，比方：经过factory扶助多种数据库保存，引入了cache体制，供给了更为便当的sql helper，但也同声带来了另少许题目。个中，最烦恼的即是sql语句的引入，并且仍旧对准各别数据库保存的各别sql语句（主假如sql server与oracle的参数表白办法各别）。另一上面，petshop固然没有运用dataset而代之以更为简略的普遍实业东西（model），但它仍旧将datareader的截止变换到了包括实业东西的列表汇合中供离线运用，从这个意旨上说，堪称换汤不换药。以至，在某些场所，比方：须要举行数据过滤，大概在主从数据间导航，相反更为未便（此时，大略的collection大概list是没辙满意需要的，dba与dal开拓职员只能再供给其它的本领来到达手段）。从上述两个例子中，咱们不妨看出，纵然在微软的开拓共青团和少先队中，也没有不妨在dal这个题目上完毕普遍。这上面的更精细消息，有爱好的伙伴不妨参考如次作品：http://www.microsoft.com/china/community/column/67.mspx。实战上头领会的两个处置计划，让咱们看到了它们各自的上风与不及，而企业级运用的搀杂情况也不太大概诉求一个放之四海而皆准的框架就能处置一切困难，所以，只能按照简直情景简直领会。作家已经介入一个（.net）巨型外包项手段开拓处事，有幸一睹其dal的安排思维，深感振动，在此与诸位伙伴一道共通商量。以sql server所带northwind数据库为例，如次即是一段鉴于该dal的挪用代码（作家做了少许称呼上的安排）：// 按照employeeid归来其titleboemp = new employeedal();boemp.keys[“emp_id”] = 1; // 提防：本质字段名为：employeeidboemp.select();string strtitle = boemp[“emp_title”]; // 提防：本质字段名为：title……// 按照 city 归来一切适合前提的 employeeboemp = new employeedal();boemp.keys[“emp_city”] = “seattle”;boemp.select(); // 提防：该本领与上头的挪用实足沟通datatable dtemp = boemp.table;即使不商量东西创造（不妨沿用object pooling大概cached object）以及挪用后的处置，本质的代码惟有两行！更让人诧异的是，上述employeedal类没有任何真实意旨上的实行代码，只是是声领会类名，而后从一个通用基类接受罢了！！最优美的场合还不在乎此，本质上，就算在谁人基类中，也基础看得见sqlconnection大概oracleadapter之类的帮派之争。断定大师也猜出来了，没错，它是模仿了petshop的实行，沿用了factory形式来保护dal不妨实用于各别的数据库保存。然而，这种实行与petshop仍旧有很大的辨别：起码，它没有爆发各别的sql语句，更没有展示各别的参数挪用办法（sql server中普遍运用“@”标记，oracle中普遍运用“：”标记），一切帮派等量齐观！这个中，固然成绩于factory的实行本领，但更要害的成分还在乎安排办法的精巧。本来，在.net framework中，仍旧供给了这种安排办法的基石，道白了，即是system.data中的那些interface（如：idbconnection，idataadapter等）。在如许的安排普通上，咱们对准每一个dal类，就不复须要为各别的数据库保存供给各别的数据存取实行了。比方：在petshop中，对准订单数据须要实行order类，很天然的，体例为sql server与oracle辨别实行了order类并运用各别provider（sqlclient，oracleclient）供给的本领举行操纵。而在本质挪用时，petshop经过factory形式动静创造真实的order类并激活相映的本领，一个面向各别数据库保存的计划就绘声绘色。本来，petshop这种计划仍旧比拟精巧了，即使更能省去“撰写各别order类”之苦，那就真的送佛送给天了j。而一切那些功效，在作家所介入的这个名目中，仍旧实足搞定了！至于上头的“employeedal（固然，囊括其它一切dal类）没有任何真实实行代码”，只然而玩了一个小小的摆设本领罢了：将各别的dal类与关系的stored procedure（请提防：不是table或view）依照namespace辨别保存到xml文献中。大概大师仍旧看出来了，表面上，以至只须要一个dal类就不妨实行上述一切的处事！但在本质操纵中，各别的dal类大概仍旧有少许数据处置上的纤细分辨（比方：数据校验，方法变换等）。总的来说，在如许一个大名目中，不大概诉求一切开拓职员（除去dba，dal framework developer）都去领会ado.net的方上面面，固然作家对此颇有接洽，但在这个名目中，却自始至终只用到了两个类：datatable，dataview（以至连transaction都无需领会）！