一、两层结构的ASP应用有何缺点
在Browser/Server 应用程序开发领域，微软公司的IIS/ASP以其强大的功能，良好的扩展能力，及与其它微软产品的一致性，迅速地流行起来。它能使一个具有VB/VC经验的程序员，很快地成为一个Web程序员，开发出看上去非常专业的应用。但是，ASP有一个天生的缺点，就是ASP代码和HTML代码是混在一起的，ASP程序员既需要考虑与数据库打交道，需要关心如何与HTML配合，有时还需要用ASP直接生成HTML代码。其结果是，当程序逻辑足够复杂时，.asp源文件非常长；而且，无论客户提出用户界面的改变，还是商业逻辑的改变(比如，在考试系统中，"合格"的标准可能从达到60分就算合格，改为进入前100名才算合格)，都需要对.asp文件进行改动，而商业逻辑的改变，很可能需要改动很多文件。

二、三层结构的概念
在传统的Client / Server应用中，也存在着上述同样的问题，多层结构的应用正是在对C/S 结构的总结基础上产生的，并且也已经扩展到了B/S应用开发领域。 即将应用划分为三层(可以有更多层，但三层最常见): 用户界面层，商业逻辑层，数据库层。 用户界面层负责处理用户的输入和向用户的输出，但并不负责解释其含义(出于效率的考虑，它可能在向上传输用户输入前进行合法性验证)，这一层通常用前端工具(VB，VC，ASP等)开发;商业逻辑层是上下两层的纽带，它建立实际的数据库连接，根据用户的请求生成SQL语句检索或更新数据库，并把结果返回给客户端，这一层通常以动态链接库的形式存在并注册到服务器的注册簿(Registry)中，它与客户端通讯的接口符合某一特定的组件标准(如COM，CORBA)，可以用任何支持这种标准的工具开发;数据库层负责实际的数据存储和检索。 有了这样的结构，上面的问题迎刃而解:还是以考试系统中的合格标准为例，在客户端所有需要显示合格人员名单的地方，调用这样一个函数GetQualifiedList，至于这个函数如何编写，如何与数据库打交道，以至访问的是何种数据库都与其无关(你一定有过这样的经历，在一种数据库系统上运行得很好的SQL语句，有时换到另一种数据库系统上必须加以修改); 在中间层DLL中实现这个GetQualifiedList函数，如果用户对"合格"的定义变了，只需要修改这个函数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这里，我们看到了面向对象编程的特性之一封装性的优点，而这一点在开发大型应用时尤其有用--我们可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作必须等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档作支持。

你也许会问，如果我把这些函数些在一个单独的文件中，再在需要调用的地方把它包含进来，不是同样能达到目的吗? 第一，这种方法效率不高，无论你把这些函数分散到多少个文件中，当你需要调用其中一个时，总会包含进一些实际上并不需要的函数，这无疑加重了服务器的负担，对服务器性能要求较高的Web应用尤其如此。 而DLL只在需要时才调入内存且只调入需要的函数，并且多个应用程序实例可以共享同一

[1] [2] [3] [4] [5] [6] [7] 下一页