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

 

u     其它

Ø        ASTA

经常在Delphi下进行网络数据库应用开发或者曾经使用过Borland Midas技术的朋友，对ASTA应该不会陌生。

如果说基于ADO.NET或O/R Mapping来实现DAL是少林、武当的正宗心法，那ASTA就有点明教“乾坤大挪移”的味道：将整个DAL中的Data Access几乎完全扔到了另一个地方（和打回原处稍有区别，但也算另一种挪移J）进行处理！

 

传统的DAL实现大都是这样的：

 

ASTA则另辟蹊径，额外加入了一个“中间层”：

      

一般来说，中间层的引入是为了提高灵活性，减少耦合度，

ASTA就是利用了这个特性设计出来的。

       上图的一个关键点就在于ASTA Client与ASTA Server之间

的那个“网络连接”，ASTA技术正是利用了网络特性，间接地

屏蔽了不同数据库系统间的差别，使开发人员在设计DAL时完

全不用知道Database的存在！这种情况有点像浏览器，完全不

用知道HTML页面是来自于IIS还是Apache，只需要知道自己

是利用HTTP协议通过网络来获得HTML页面！

      

在ASTA中，浏览器就是ASTA Client，HTML页面就是ASTA DataSet（与ADO.NET中的DataSet在格式上有区别，此处可以认为是另一种数据库无关的数据集合表示方式），而IIS、Apache就是ASTA提供的不同的ASTA Server（目前支持大部分主流数据库系统，开发人员也可以撰写自己的ASTA Server），HTTP协议自然就是ASTA Client与ASTA Server间的通信协议！

从技术上分析，ASTA架构的目的之一就是利用自己提供的协议来屏蔽不同数据库系统的网络通信协议，从而使客户端（DAL）完全摆脱在编写网络数据库应用时的通信难题！

（作者还记得，.NET出来前，每次在编写面向Internet 的SQL Server应用程序时，除了需要配置连接字符串，还要在客户端特别安装SQL Server Client Network Utility以配置Internet连接，不说SQL Server暴露端口引起的安全问题，就是这么一番折腾也让人够呛的J）

 

在ASTA下编写程序非常舒服，只要知道ASTA Server的地址和端口，再提供一定权限的用户名、口令（ASTA自带的认证系统，开发人员也可以撰写自己的Authentication/Authorization模块，甚至直接利用数据库系统提供的验证机制），立刻就能得到任何数据库的任何数据信息！而且，一旦数据库系统有所变动（如从SQL Server切换到Oracle，但不包括数据库结构的改动），客户端根本无须任何修改！

                                   ASTA技术不足处也是很明显的：由于引入了在某些情况下

（如一次返回数据量很大时）足以致命的“网络中间层”，使开

发人员在开发大型应用（尤其是面向Internet的企业级应用）时

需要特别小心，毕竟，舒服在某些时候是需要付出一定代价的！

      

       有兴趣的朋友不妨去这个网站看看：

       http://www.astatech.com

      

Ø        .NET Remoting / WebServices

原来不准备将.NET Remoting / WebServies拿出来凑热闹，毕竟，这两种技术不是为DAL度身定做的。

无奈，偏偏就是看到有朋友这么用过，后来细想，发现也颇有一些道理，就拿出来与大家一起参详参详。

其实，虽然微软大肆宣传XML WebServices，但就技术来看，其实只要论述.NET Remoting一种就可以了，XML WebServices无非就是在.NET Remoting中使用了HTTP + SOAP通信协议的一种特例而已。

 

.NET Remoting应用到DAL中可能出于两种目的：

（1）    希望实现跨平台数据访问，因为ADO.NET中的DataSet是可以被序列化的，通过Remoting或WebServices可以在客户端恢复现场；

 

（2）    减轻服务器压力，增加系统灵活性。

这有点类似于上面的ASTA技术，只不过这里的协议

换成了.NET Remoting Protocal。但即使用这种方式，

还是和ASTA的灵活性有区别，毕竟，Remoting要

求在客户端注册每一个DAL的访问接口，一旦接口

变化，接口必须重新注册！

                                  

                                所以，作者的建议是：尽量避免使用.NET Remoting来

构建应用程序的DAL模块（如果是Business Logic Layer，则不

存在这个问题），除非真的是“迫不得已”（例如：必须在DAL

层实现分布式计算或者客户坚持使用.NET Remoting J）！

                                  

                                  

以下部分因时间限制，正在撰写中 !

l       我的方案（未完，撰写中……）

u     综合现有的技术

Ø        在DAL之上添加一个新的DAF Layer：Data Access Facade

n        使用DataSet / DataTable / DataView + Cache Management

n        使用ObjectSpaces / ECO + ADO.NET + Stored Procedure

Ø        ……

u     使用现成的框架

Ø        开源项目推荐使用OPF（国外）

Ø        商业产品推荐使用Grove（国内）

Ø        ……

u     设计自己的持久层

Ø        如果希望自己设计轮子，那么，最好的参考资料莫过于这篇文章：http://www.ambysoft.com/persistenceLayer.pdf

Ø        ……

 

l       小结（未完，撰写中……）

l       参考（未完，撰写中……）

 

 

特别说明：

“我的方案”已完成，请参考如下链接：

http://www.csdn.net/develop/Read_Article.asp?id=27542

 

 

作者简介：

“本文作者张雪峰 是 毕博全球开发中心 的高级开发工程师。他目前在中国上海 毕博全球开发中心 Core/EAI 部门工作，从事 .NET 技术的研究以及相关项目的开发。可以通过 [email protected] 与他联系。”

 

本文地址：http://com.8s8s.com/it/it44922.htm