1,178
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
疯狂低调 2003-10-15
- 打赏
- 举报
感谢，小弟也是看过了上面的帖子之后才对三层有了准确地认识。
收藏
收藏
icemanpro 2003-10-09
- 打赏
- 举报
所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
这样的好处显而易见：
1、 由于数据访问是通过中间层进行的，因此客户端不再与数据库直接建立数据连接。也就是说，建立在数据库服务器上的连接数量将大大减少。例如一个500个客户端的应用系统，500个客户端分别与中间层服务器建立DCOM连接，而DCOM通讯所占用的系统资源极为有限，并且是动态建立与释放连接，因此客户端数量将不再受到限制。同时，中间层与数据库服务器之间的数据连接通过“连接池”进行连接数量的控制，动态分配与释放数据连接，因此数据连接的数量将远远小于客户端数量。
2、 可维护性得以提高。因为业务规则、合法性校验存在于中间层，因此当业务规则发生改变时，只需更改中间层服务器上的某个组件（如某个DLL文件），而客户端应用程序不需做任何处理，有些时候，甚至不必修改中间层组件，只需要修改数据库中的某个存储过程就可以了。
3、 良好的可重用性。同样，如果需要开发B/S应用，则不必要重新进行数据访问、业务规则等的开发，可以直接在WEB服务器端调用现有的中间层（如可以采用基于IIS的WebClass开发，或直接编写ASP代码）。
4、 事务处理更加灵活，可以在数据库端、组件层、MTS（或COM+）管理器中进行事务处理。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
这样的好处显而易见：
1、 由于数据访问是通过中间层进行的，因此客户端不再与数据库直接建立数据连接。也就是说，建立在数据库服务器上的连接数量将大大减少。例如一个500个客户端的应用系统，500个客户端分别与中间层服务器建立DCOM连接，而DCOM通讯所占用的系统资源极为有限，并且是动态建立与释放连接，因此客户端数量将不再受到限制。同时，中间层与数据库服务器之间的数据连接通过“连接池”进行连接数量的控制，动态分配与释放数据连接，因此数据连接的数量将远远小于客户端数量。
2、 可维护性得以提高。因为业务规则、合法性校验存在于中间层，因此当业务规则发生改变时，只需更改中间层服务器上的某个组件（如某个DLL文件），而客户端应用程序不需做任何处理，有些时候，甚至不必修改中间层组件，只需要修改数据库中的某个存储过程就可以了。
3、 良好的可重用性。同样，如果需要开发B/S应用，则不必要重新进行数据访问、业务规则等的开发，可以直接在WEB服务器端调用现有的中间层（如可以采用基于IIS的WebClass开发，或直接编写ASP代码）。
4、 事务处理更加灵活，可以在数据库端、组件层、MTS（或COM+）管理器中进行事务处理。
icemanpro 2003-10-09
- 打赏
- 举报
三层数据库与应用程序服务器的澄清事实
应用程序服务器主要解决两个问题
一客户/服务器模式中：数据库服务器负责连接问题（项羽兄遇到了）
二网站要动态地更新数据及数据库要上互联网连接问题
还有其他方面的应用不说了。
第一模式应用环境主要是局域网中：客户程序+应用程序服务器+数据库
第二模式应用在互联网中：浏览器+WEB服务器+应用程序服务器+数据库
局域网中可以采用浏览器，互联网中也可客户程序。
可以想象出局域网中可以大数据量流，互联网中必须小数据量流。
规则应用何处？
采用应用程序服务器后，大家取得共识收交了客户端上的规则。
有的人把规则放到应用程序服务器中，能减轻数据库的工作负荷。
我认为规则还是让数据库去管理，数据库的能力比我们强。
只有一些很老的数据库管理规则能力很低，或许不是关系型数据库
应用程序服务器就得去处理规则。
应用程序服务器最好去负责连接方面，数据流量的监测，提供优质服务给客户端，
更好的兼容不同类型的，老式数据库。
目前有三种类型的应用程序服务器
微软的分散型：分散到不同的技术中。
数据库厂商：他们卖数据库时一起卖应用程序服务器（专用型）。
独立软件商：开发的独立的应用程序服务器。
适合于不同的情况。
而我们，我想是开发独立性应用程序服务器，能提供更好的灵活性，兼容性。
大家以开发时注意下将来。
C++Builder5为我们提供了开发客户端和应用程序服务器各种零件。
应用程序服务器端零件：TDataSetProvider+BDE方式零件(Table,Query...)+ADO(ADOTable....)。odbc还是通过BDE零件;SQL link我见都没见到
ADO零件不丰富没有BDE的会话，批量移动，缓存更新，嵌套表；更没有InterBase的事务，数据库信息，监测，事件。
BDE发布时复杂很，很不听话，哪怕有安装程序也无地自容。希望C++Builder6能增强ADO功能，啊Deiphl6出来了不置可否？
客户端
TDataSource+TClientDataSet+{TDCOMConnection;TSocketConnection;TWebConnection;TCorbaConnction;TSimpleObjectBroker}
五种不同的方式连接应用程序服务器.
TDCOMConnection 采用DCOM技术发布时要注意NT服务器名和域名设置，应用程序服务器也要在客户端注册DCOM。
TSocketConnection：采用TCP/IP方式可以不用NT域名服务器，连接有安全问题应用程序服务器中要启动ScktSrver.EXE来监听。
TWebConnection: 采用HTTP方式，它却是连接的是WEB服务器，通过它传数据给应用程序服务器。发布时客户端要Wininet.dll只要装了IE3以上系统自带；
WEB服务器必须是IIS4 UP 或者Netscap enterprise3.6 up；
WEB服务端要有HTTPsrvr.dll；
TWebConnection->URL="HTTP://MIDASHOST.ORG/scripts/httpsrvr.dll"。
TSimpleObject: TOLEnterpriseConnection简单版为了向后兼容，好处在于连接应用程序服务器组，能随机选择，使应用程序服务器负载平衡，由4个部分组成
1Broker.exe
2ObjFact.exe
3OLECFG.exe
4OLEntExp.exe
1+2放在应用程序服务器Broker.exe先运行；3 和4是配置工具。不能单独使用ClientDataset+DCOM+Simpleobject
TCorbaConnction: 我没有这个家伙不好说！！
所有的客户端要同时发布MIDAS.DLL。具体情况具体分析，我不多说了。报纸新闻说加入了WTO要企业上信息系统，我学过信息系统很复杂涉及到管理方法和人际关系，但要数据库支持，三层数据库必是首先。我们有英雄有用武之地，VC VB 还嫩着点了。
应用程序服务器主要解决两个问题
一客户/服务器模式中：数据库服务器负责连接问题（项羽兄遇到了）
二网站要动态地更新数据及数据库要上互联网连接问题
还有其他方面的应用不说了。
第一模式应用环境主要是局域网中：客户程序+应用程序服务器+数据库
第二模式应用在互联网中：浏览器+WEB服务器+应用程序服务器+数据库
局域网中可以采用浏览器，互联网中也可客户程序。
可以想象出局域网中可以大数据量流，互联网中必须小数据量流。
规则应用何处？
采用应用程序服务器后，大家取得共识收交了客户端上的规则。
有的人把规则放到应用程序服务器中，能减轻数据库的工作负荷。
我认为规则还是让数据库去管理，数据库的能力比我们强。
只有一些很老的数据库管理规则能力很低，或许不是关系型数据库
应用程序服务器就得去处理规则。
应用程序服务器最好去负责连接方面，数据流量的监测，提供优质服务给客户端，
更好的兼容不同类型的，老式数据库。
目前有三种类型的应用程序服务器
微软的分散型：分散到不同的技术中。
数据库厂商：他们卖数据库时一起卖应用程序服务器（专用型）。
独立软件商：开发的独立的应用程序服务器。
适合于不同的情况。
而我们，我想是开发独立性应用程序服务器，能提供更好的灵活性，兼容性。
大家以开发时注意下将来。
C++Builder5为我们提供了开发客户端和应用程序服务器各种零件。
应用程序服务器端零件：TDataSetProvider+BDE方式零件(Table,Query...)+ADO(ADOTable....)。odbc还是通过BDE零件;SQL link我见都没见到
ADO零件不丰富没有BDE的会话，批量移动，缓存更新，嵌套表；更没有InterBase的事务，数据库信息，监测，事件。
BDE发布时复杂很，很不听话，哪怕有安装程序也无地自容。希望C++Builder6能增强ADO功能，啊Deiphl6出来了不置可否？
客户端
TDataSource+TClientDataSet+{TDCOMConnection;TSocketConnection;TWebConnection;TCorbaConnction;TSimpleObjectBroker}
五种不同的方式连接应用程序服务器.
TDCOMConnection 采用DCOM技术发布时要注意NT服务器名和域名设置，应用程序服务器也要在客户端注册DCOM。
TSocketConnection：采用TCP/IP方式可以不用NT域名服务器，连接有安全问题应用程序服务器中要启动ScktSrver.EXE来监听。
TWebConnection: 采用HTTP方式，它却是连接的是WEB服务器，通过它传数据给应用程序服务器。发布时客户端要Wininet.dll只要装了IE3以上系统自带；
WEB服务器必须是IIS4 UP 或者Netscap enterprise3.6 up；
WEB服务端要有HTTPsrvr.dll；
TWebConnection->URL="HTTP://MIDASHOST.ORG/scripts/httpsrvr.dll"。
TSimpleObject: TOLEnterpriseConnection简单版为了向后兼容，好处在于连接应用程序服务器组，能随机选择，使应用程序服务器负载平衡，由4个部分组成
1Broker.exe
2ObjFact.exe
3OLECFG.exe
4OLEntExp.exe
1+2放在应用程序服务器Broker.exe先运行；3 和4是配置工具。不能单独使用ClientDataset+DCOM+Simpleobject
TCorbaConnction: 我没有这个家伙不好说！！
所有的客户端要同时发布MIDAS.DLL。具体情况具体分析，我不多说了。报纸新闻说加入了WTO要企业上信息系统，我学过信息系统很复杂涉及到管理方法和人际关系，但要数据库支持，三层数据库必是首先。我们有英雄有用武之地，VC VB 还嫩着点了。
icemanpro 2003-10-09
- 打赏
- 举报
浅谈如何建立三层体系结构的ASP应用程序
随着互连网应用的深入和发展，三层体系结构的应用模式也得到更多人的青睐。本文介绍了三层结构应用程序的概念和优点，并结合一个实例介绍了如何建立三层结构的ASP应用程序。
一、两层结构的ASP应用有何缺点
ASP有一个天生的缺点，就是ASP代码和HTML代码是混在一起的，ASP程序员既需要考虑与数据库打交道，需要关心如何与HTML配合，有时还需要用ASP直接生成HTML代码。其结果是，当程序逻辑足够复杂时，.asp源文件非常长；而且，无论客户提出用户界面的改变，还是商业逻辑的改变(比如，在考试系统中，"合格"的标准可能从达到60分就算合格，改为进入前100名才算合格)，都需要对.asp文件进行改动，而商业逻辑的改变，很可能需要改动很多文件。
二、三层结构的概念
在传统的C/S应用中，也存在着上述同样的问题，多层结构的应用正是在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.一旦对象被释放，这些值会被一起释放。
随着互连网应用的深入和发展，三层体系结构的应用模式也得到更多人的青睐。本文介绍了三层结构应用程序的概念和优点，并结合一个实例介绍了如何建立三层结构的ASP应用程序。
一、两层结构的ASP应用有何缺点
ASP有一个天生的缺点，就是ASP代码和HTML代码是混在一起的，ASP程序员既需要考虑与数据库打交道，需要关心如何与HTML配合，有时还需要用ASP直接生成HTML代码。其结果是，当程序逻辑足够复杂时，.asp源文件非常长；而且，无论客户提出用户界面的改变，还是商业逻辑的改变(比如，在考试系统中，"合格"的标准可能从达到60分就算合格，改为进入前100名才算合格)，都需要对.asp文件进行改动，而商业逻辑的改变，很可能需要改动很多文件。
二、三层结构的概念
在传统的C/S应用中，也存在着上述同样的问题，多层结构的应用正是在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.一旦对象被释放，这些值会被一起释放。
