IDC资讯中心
本文是编译稿件，原文出处：http://www.asptoday.com/articles/20000121.htm
你刚刚把最新的庞大的asp应用程序释放到网上。文件正确地上载到服务器上，与应用程序的链接也
工作良好。在庆祝胜利之前，你想在应用程序的性能上运行一些stats 以便发现它到底有多好。结果
却发现，本来在开发环境下工作得很好的应用程序实际上运行速度很慢。
对于那些使用microsoft 软件包时间不长的人，dna代表分布式internet 结构，是另一种非常热门的
n层应用程序结构的首字母缩写形式。microsoft 致力于在internet上展开的分布式应用程序的开发。
基于这种思路，未来将流行小型的、无状态的、组件化的应用程序就不足为奇了。
上面是asp用于n层环境的典型图示。web类（iis应用程序）不是必需的，因为asp可以直接与表述层
或商业规则层组件对话。因为大多数应用程序都是用asp单独写成的，所以一个情理中的问题就是：
为什么要将代码转入com组件？
以我之见，asp只是用于表述层代码的，所以我选择将商业规则逻辑或任何形式的数据存取
都装入com组件中。一般情况下，我从一开始就将应用程序的代码分成各个组件，但是通常你并不能选
择所要处理的结构，所以代码移植就是个实际问题。在一个n层应用程序中，你必须尽力把非表述代码
从asp中尽快移走。
也许目前你并没有在进行n层编程，那么移植代码的适当时机就是运行性能开始削弱时。通常，这是指
你的老板说“程序今天运行有点慢”到“你被解雇了”之间这段时间。一旦用户开始抱怨就晚了。
第二个使用移植代码的方针是当你有足够的相似代码（例如所有的数据存取）可以放在一个包含文件
(.inc) 中以保证一个com组件时。多少个程序就足够？这个问题提得好！编写小型的mts 组件时，我
发现有一个程序就足够创建一个com组件了。但是只有一个程序的com组件是很罕见的，所以对于这个
问题就需要进行判断。如果你写的代码足够长，就开始进行模式开发了。当你遭遇到asp的“阴暗面”
之后（aka com组件）你就会感觉到其力量。
