WP01 – 为什么实现Multi-Tier, 为什么使用 Data Abstract?
WP01 –
为什么实现
Multi-Tier,
为什么使用
Data Abstract?
RemObjects
软件白皮书
本文简要并高度概括地介绍
Data Abstract,
为什么要创建他
,
为什么他是数据库应用中的首选
.
Data Abstract
经常以多层架构被提及
,
就是说他基于可分为多个级别
/
层次
(
通常是三层
)
数据接口原则
.
要理解为什么多层数据接口是很多情形的首选
,
我们需要看看要使用的数据接口原理
.
回到
90
年代的客户端
/
服务器模式
早在
90
年代
(
或以前
),
存在两种类型的数据库应用程序
,
称为
:
桌面和客户端
/
服务器应用程序
.
术语桌面数据库应用程序就是经常提及的单用户直接连接到本地数据库
(
如安装在用户电脑上的
dBase,Paradox
或
FoxPro
等
)
的应用程序
.
在网络普及之前
,
这样的应用程序通常只是一个不能连接到外边也不能与其他系统或用户共享数据的单独的程序
.
更高级一点的
,
就是客户端
/
服务器应用程序
,
他在架构上继承了很多桌面系统的特性
,
但是其连接到一个运行于可供多个用户共享的计算机网络中专门的服务器
(
组
)
的巨型数据库系统
.
这两种常见的桌面应用程序及客户端
/
服务器应用程序
(
我们可以发现客户端
/
服务器主要的弱点
)
通常都是将业务逻辑集中与应用程序
,
难道数据库这是做数据存储的容器吗
?
客户端
/
服务器应用程序在很多方面受限与他的架构
:
- 由于所有的业务逻辑在客户端程序中实现,执行业务逻辑的代码必须提供网络分发复制到每个工作站. 修改业务逻辑必须向所有用户重新发布客户端应用程序. 需要更多的人力来管理系统.
- 另外一个问题是由于业务逻辑存放在客户端,无法保证客户端安全而使系统容易收到攻击. 客户端软件要在一个公司的数百台计算机上安装或不在控制的网络之内,这就无法保证会有恶意用户破解客户端软件或执行他们自己写的程序连接到数据库,或绕过密码检测而执行所有的业务逻辑.
- 基于上面讲述的事实,由于客户端/服务器的架构问题,终端数据库必须能被每天客户端打开.然而现在的先进数据库提供了复杂的验证机制,在网络中代开数据库是很危险的行为.首选,常用的数据库都是很容易收到攻击的,黑客可以利用这点危及系统安全.其次,由于客户端系统本身需要向服务器提交验证,验证信息很容易从客户端提取.
- 最后,由于很多数据库的网络接口是有为本地网络设计的,使用快速的连接并没有防火墙.现今,很多客户端需要运行在外网.即使不考虑在外网代开数据库连接的危险性,这样的连接也是不可靠,无效率的.
Multi-Tier
方案
多层架构是如何解决这个问题的呢
?
很简单
:
并客户端
/
服务器
(
就是常说的两层系统
)
多出一个数据接口层
,
每个层都只执行自己的任务
.
理论上三层架构可以由多个层组成
,
最常用的就是三层解决方案
,
大致保持了客户端和服务器的概念
,
并在其中添加了第三层
(
常叫做中间层或业务逻辑层
).
总体上看
,
中间层主要有如下作用
:
- 将客户端程序与数据库服务器分离
- 在一个方便控制的地方实现业务逻辑.
隔离客户端与数据库
,
意味着客户端应用程序不再与数据库服务器直接连接和通讯
,
他们不再直接读取数据表和数据库的原始定义数据
.
所有的读取和操作数据库都要经过完全控制数据存取接口的中间层
.
在中间层实现业务逻辑
,
意味着只有一个强制的规则中心
,
由于所有的数据接口必须经过中间层
,
就不会出现客户端绕过密码检查规则了
.
中间层服务器通常部署在安全的位置
,
例如与数据库服务器处于同一个服务组
,
并只向网站中开放有限的接口给客户端
.
通过标准的
Internet
协议如
HTTP
或
Web Service
保证无缝的在广域网内工作
.
与客户端
/
服务器相比
,
客户端应用程序叫做瘦客户端
,
只向终端用户提供一个丰富的用户界面
,
所有保证数据完整性的处理都在中间层完成
.
很严重的攻击或其他客户端为威胁还能获取数据读取的权限并执行没有任何限制的修改吗
?
这一切都将被中间层拒绝
.
为什么用
Data Abstract
替代其他的架构
?
Data Abstract
当然不仅仅是一个多层数据库架构
,
什么特点使其可以在一个解决方案中能同时响应数千个客户端
?
关于这些
Data Abstract
的优点和高级概念超出了白页的范围
,
所以我们只集中谈谈两个主要概念
.
理由
#1:
为多层架构提供完整的端到端的解决方案
当今很多数据库架构都支持多层
,
但不是所有的都从底层开始设计多层支持
.
例如现在的微软数据库架构
ADO.NET 2.0. ADO.NET
当然是准备用于多层解决方案的
,
并提供了一些特性使之可以更好的适应多层应用
,
但是距离基于三层特性的数据层和为三层而设计的全面架构还有很大的距离
.
例如
,ADO.NET
基于无连接的数据集
,
意味着客户端基于从终端数据库取得的数据集
,
并在无数据库连接的情况下工作
,
修改这些数据
,
最后保持会数据库
.
但是这只是多层架构的一个方面
,
是一个完整版图的一小部分
.
例如
,ADO.NET
提供了绝对无限制的分离客户端和中间层
,
但是却没有提供两个层的通讯的解决方案
.
这需要开发人员重复制造车轮并最后并凑在一起
.
*
事实上
, Data Abstract .NET
版本部分基于
ADO.NET,
并在多层设计的时候充分利用了它们
.
但是这里扩展了
ADO.NET
对多层应用的支持
.
相比而言
, Data Abstract
为多层数据应用提供了全面的架构支持
,
不仅仅是数据接口
,
还包括
:
- 客户端服务端如何通讯.
- 运行时如何验证客户端.
- 数据检索是如果在客户端和服务端传递参数和条件.
- 如果在数据中应用业务规则
- 如果更新失败,如何从服务端想客户端传递错误条件.
Data Abstract
提供一致的架构解决这些问题
.
令人惊奇的是有些
Data Abstract
服务端不需要写多少代码
.
要创建一个新的服务只需要在开发
IDE
向导中点击几个按钮
,
就可以生成一个功能完整并自动部署的中间层服务端
.
这并不是说
Data Abstract
只能让开发者使用这种方式
.
恰恰相反
, Data Abstract
的一个基本设计原则就是提供一个开放的架构允许开发者使用各种方式实现多层
. Data Abstract
提供了一个清晰的路径对每一种三层架构情形推荐模式解决方案
,
但是开发者可以随时随地修改这些部分
.
由负责项目的架构师或独立的开发者决定是否完全使用
Data Abstract
架构
(
实际项目中是合理的
),
或基于项目要求加入自己的处理过程
.
理由
#2:
数据库以不可预知的方式运行在中间层
事实上所有的中间层代码都有数据库紧耦合
.
开发人员要对特定数据库写很多代码或拖放很多控件配置并直接存取数据库中的表
.
通常这些代码或控件要包含自动生成或手动加入的硬编码的
SQL
命令来获取数据或执行更新
.
很多情况
,
在一个简单的应用程序中读取两三个表看起来很完美
,
很快变得笨拙
,
更重要的是当处理几十上百的表可能的维护量
.
随着应用程序的生命周期推移这些都可能变化并发展的
.
Data Abstract
通过引入
定义中间层的数据接口结构和层次并开放给客户端的
Schemas
概念提供了基本上不同的方式
.
Schema
是一个基于
XML
的文件
,
并结构化风格化的定义了应用程序使用的数据表
. Schema
抽象实际的数据库及其中的细节关系
.
如何获取和更新数据
,
在中间层的实际代码中使用什么样的
SQL
语法
?
基本上
,Schema
定义了一个你的项目需要协同工作的数据视图
,
通过它可以将处理实际需要的数据接口的繁琐工作分离出来
.
这样
,
开发者可以集中精力写客户端和应用程序的业务逻辑
,
因为所有的数据接口都通过
Data Abstract
的
Schema
定义信息无缝的处理
.
Data Abstract
为
Schema Modeler™
提供了强大的功能
-
使开发者或架构师以
RAD
的方式定义他们项目中的
Schema. Schema Modeler
完全深入的支持开发环境
,
同时为非开发人员提供舒适的用户接口
,
允许项目组成员分工合作
,
如让数据库管理员定义开发人员要编码时使用的
Schema.
由于所有的数据接口定义在
Schema
中
,Data Abstract
在运行时自动提供一个中间层服务需求框架
,
开发者可以集中精力实现业务逻辑和客户端应用程序
.
节省了自己去实现数据接口是的时间
.
使用
Data Abstract
的
Schema
的另外一个高效原因在于业务逻辑代码不知道具体的数据库
,
不会和数据库绑定
.
不用修改代码只对
Schema
做少许修改就可使应用程序适用于不同的终端数据库
.
Data Abstract
的
schemas
是一个强大灵活的概念
,
上面说的对于他给你的多层架构所带来的好处只是九牛一毛
.
更多信息请参考
"WP02 Schemas
和
Data Abstraction
等文档
.
总结
本文高度总结了多层架构和可创建强大可靠的数据库解决方案的首要架构
Data Abstract.
更多信息办好在其他的白页和技术文档中
.
点击查看
www.remobjects.com/multi-tier.