剖析.Net下的数据访问层技术(6)

核心提示：其它ASTA经常在Delphi下进行网络数据库应用开发或者曾经使用过Borland Midas技术的朋友，对ASTA应该不会生疏，剖析.Net下的数据访问层技术(6)，假如说基于ADO.NET或O/R Mapping来实现DAL是少林、武当的正宗心法，那ASTA就有点明教“乾坤大挪移”的味道：将整个DAL中的Data

　　其它
　　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，但不包括数据库结构的改动），客户端根本无须任何修改！
　　
　　STA技术不足处也是很明显的：由于引入了在某些情况下（如一次返回数据量很大时）足以致命的“网络中间层”，使开发人员在开发大型应用（尤其是面向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）！