剖析 .Net 下的数据访问层技术（六）
日期：2012-03-12 浏览次数：20464 次
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 参考（未完，撰写中……）
Ø 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 参考（未完，撰写中……）
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
