SQL Server 2005 Mobile Edition 3.0 中的复制和远程数据访问功能的技术对比

核心提示： 很多的J2EE应用程序需要使用持久性数据(数据库、文件等)，不同的程序，SQL Server 2005 Mobile Edition 3.0 中的复制和远程数据访问功能的技术对比(10)，持久性存储是各不相同的，并且用来访问这些不同的持久性存储机制的API也有很大的不同，即访问这些独立系统的API很不统一，3.组件需

　　很多的J2EE应用程序需要使用持久性数据(数据库、文件等)。不同的程序，持久性存储是各不相同的，并且用来访问这些不同的持久性存储机制的API也有很大的不同。如果应用程序要在不同的持久性存储间迁移，这些访问特定持久存储层的代码将面临重写。

　　如何解决这个问题?且看"DAO模式"

　　数据访问对象(Data Acess Object) 模式

　　一.环境

　　根据数据源不同，数据访问也不同。根据存储的类型(关系数据库、面向对象数据库、文件等等)和供应商实现不同，持久性存储(比如数据库)的访问差别也很大。
　
　　二.问题

　　许多真是的J2EE应用程序需要在一定程度上使用持久性数据。对于许多应用程序，持久性存储是使用不同的机制实现的,并且用来访问这些不同的持久性存储机制的API也有很大的不同。

　　比如，应用程序使用实体bean(这里应该是指BMP的bean，CMP的bean已大大降低了与RDBMS的耦合)的分布式组件来表示持久性数据，或者使用JDBC API来访问驻留在某关系数据库管理系统(RDBMS)中的数据，这些组件中包含连接性性和数据访问代码会引入这些组件与数据源实现之间的紧密耦合。组件中这类代码依赖性使应用程序从某种数据源迁移到其他种类的数据源将变得非常麻烦和困难。当数据源变化时，组件也需要改变，以便于能够处理新类型的数据源。

　　(举个例子来说，我们UPTEL系统是使用JDBC API对 Oracle(大型网站数据库平台)数据库进行连接和数据访问的，这些JDBC API与SQL语句散布在系统中，当我们需要将UPTEL迁移到其他RDBMS时，比如曾经迁移到INFORMIX，就面临重写数据库连接和访问数据的模块。)

　　三.作用力

　　1.诸如bean管理的实体bean、会话bean、servlet等组件往往需要从持久性存储数据源中检索数据，以及进行数据存储等操作。

　　2.根据产品供应商的不同，持久性存储API差别也很大，这些API和其能力同样根据存储的类型不同也有差别，这样存在以下缺点，即访问这些独立系统的API很不统一。

　　3.组件需要透明于实际的持久性存储或者数据源实现，以便于提供到不同供应商产品、不同存储类型和不同数据源类型的更容易的移植性。