关于网友提出的“ 关于三层结构的基本应用”问题疑问，本网通过在网上对“ 关于三层结构的基本应用”有关的相关答案进行了整理，供用户进行参考，详细问题解答如下：
问题： 关于三层结构的基本应用
描述: 三层结构的在我们身边平常人能接触到的最典型应用例子.谁能列举一二吗?简要说说它的三层结构工作或联系原理更好.
解决方案1: www.source520.com 免费免注册80G源码书籍下载
解决方案2: 举几个例子：
1，数据库资源共享，你可以在中间层做个连接池，所有的数据库连接都放在那里，不用分散到多个客户端里；
2，把业务逻辑放到中间层，在软件版本升级的时候，只需升级中间层(理想情况下，客户端很少有重要的业务逻辑，甚至没有)，打个比方：客户在最初的需求里只有两种打折方式，到后来又增加一种等情况；
3，同时带来的好处还有软件的可维护性等等。
解决方案3: 我靠，delphi的大版主都不认识，晕
解决方案4: >>简要说说它的三层结构工作或联系原理更好.
李维的基本数据库有关的书，都谈到了，
如 delphi 5.x 系列
delphi7 高效数据库
解决方案5: 三层结构的设计模式
一般简单的三层结构设计方式：
Remote Data Module服务器
数据库
Query组件
DataSetProvider组件
客户端应用程序
DCOM组件
ClientDataSet组件
现在一般介绍三层结构大多数使用上面的数据模型进行讲解，通过DataSource组件连接ClientDataSet组件，然后通过数据感知控件连接DataSource组件，来进行对数据库数据的访问。这样就使得数据库服务器、应用服务器和应用程序之间的联系过于紧密，如果其中一个做了改动，其他的都要跟着改动，对于系统的升级与维护带来很多不便。
2．新的三层结构设计模式：
Remote Data Module服务器
数据库
Query组件
DataSetProvider组件
客户端应用程序
DCOM组件
ClientDataSet组件
上面是我们现在采用的三层结构模式，它不通过DataSetProvider组件来传递数据，而是通过Remote Data Module服务器所提供的Interface来进行数据的传递。这样就使得应用程序完全与数据库服务器没有任何关系，对整个系统的升级与维护都带来极大的好处。
对于集合数据，由于Interface的返回值可以是OLEVarient类型，因此我们可以创建ClientDataSet来进行集合数据的传递。
3．部分源程序
//函数1：创建ClientDataSet
procedure CreateCds(const Ds: TDataSet; var Cds: TClientDataSet);
var
I: Integer;
begin
Cds := TClientDataSet.Create(nil);
for I := 0 to Ds.FieldCount - 1 do
begin
with Cds.FieldDefs.AddFieldDef do
begin
Name := Ds.FieldDefs[I].Name;
DataType := Ds.FieldDefs[I].DataType;
if DataType = ftAutoInc then
DataType := ftInteger;
Size := Ds.FieldDefs[I].Size;
end;
end;
Cds.CreateDataSet;
end;
//函数2：给ClientDataSet负值
procedure TransData(const Ds: TDataSet; var Cds: TClientDataSet);
var
I: Integer;
begin
if Ds.RecordCount > 0 then
begin
Ds.First;
while not Ds.Eof do
begin
Cds.Insert;
for I := 0 to Ds.FieldCount - 1 do
Cds.FielDs[I].Value := Ds.FielDs[I].Value;
Cds.Post;
Ds.Next;
end;
end;
end;
转自：动态网站制作指南 | www.knowsky.com
解决方案6: 三层结构的概念
在传统的Client / Server应用中，也存在着上述同样的问题，多层结构的应用正是在对C/S 结构的总结基础上产生的，并且也已经扩展到了B/S应用开发领域。 即将应用划分为三层(可以有更多层，但三层最常见): 用户界面层，商业逻辑层，数据库层。 用户界面层负责处理用户的输入和向用户的输出，但并不负责解释其含义(出于效率的考虑，它可能在向上传输用户输入前进行合法性验证)，这一层通常用前端工具(VB，VC，ASP等)开发;商业逻辑层是上下两层的纽带，它建立实际的数据库连接，根据用户的请求生成SQL语句检索或更新数据库，并把结果返回给客户端，这一层通常以动态链接库的形式存在并注册到服务器的注册簿(Registry)中，它与客户端通讯的接口符合某一特定的组件标准(如COM，CORBA)，可以用任何支持这种标准的工具开发;数据库层负责实际的数据存储和检索。 有了这样的结构，上面的问题迎刃而解:还是以考试系统中的合格标准为例，在客户端所有需要显示合格人员名单的地方，调用这样一个函数GetQualifiedList，至于这个函数如何编写，如何与数据库打交道，以至访问的是何种数据库都与其无关(你一定有过这样的经历，在一种数据库系统上运行得很好的SQL语句，有时换到另一种数据库系统上必须加以修改); 在中间层DLL中实现这个GetQualifiedList函数，如果用户对"合格"的定义变了，只需要修改这个函数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这里，我们看到了面向对象编程的特性之一封装性的优点，而这一点在开发大型应用时尤其有用--我们可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作必须等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档作支持。
你也许会问，如果我把这些函数些在一个单独的文件中，再在需要调用的地方把它包含进来，不是同样能达到目的吗? 第一，这种方法效率不高，无论你把这些函数分散到多少个文件中，当你需要调用其中一个时，总会包含进一些实际上并不需要的函数，这无疑加重了服务器的负担，对服务器性能要求较高的Web应用尤其如此。 而DLL只在需要时才调入内存且只调入需要的函数，并且多个应用程序实例可以共享同一个DLL实例；第二，设想一个员工，有20个属性(工号，姓名，年龄，性别......)，现在给定某工号，要求返回此员工所有信息。此时如果单纯用函数，只能定义20个全局变量，在函数中改变这些变量值，或者定义一个有20个传参(by reference)参数的函数。显然，第一种方法很麻烦而一旦增加一个属性后一种方法就需要更改函数接口。而在一个对象里，既包含成员方法(即函数和过程)，也包括成员属性。如果我们采用对象的方法，则在函数中只需要改变对象的属性，在函数外可以直接引用改变了的对象属性值。 这种方法有些类似第一种方法，但1.属性值无需在函数外逐一说明；2.这些属性值只属于对象，与对象无关的代码不会无意地改变属性值；3.一旦对象被释放，这些值会被一起释放。
以上介绍了“ 关于三层结构的基本应用”的问题解答，希望对有需要的网友有所帮助。
本文网址链接：http://www.codes51.com/itwd/3677561.html
