你刚刚把最新的庞大的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组件）你就会感觉到其力量。


 

评论 (0) All

登陆 还没注册？