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 ** 的企业级应用）时
需要特别小心，毕竟，舒服在某些时候是需要付出一定代价的！
有兴趣的朋友不妨去这个网站看看：
Ø ** .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] 与他联系。 ”