Asp.net读取Word的实例与总结 第5页
l 运行稳定性：
微软Office是主要针对普通用户开发的桌面办公应用软件，它具有丰富的UI（用户界面）元素，是一套纯粹的本地运行软件或者说是客户端软件。Word自动化接口主要是为了方便窗口应用程序调用而设计的。例如Delphi、VB、C# Winform等开发的本地应用程序。虽然可以强制Visible为false，Word可以运行在服务器端代码里，但毕竟还是会带来许多棘手问题。1. ASP.NET是基于B/S架构的。B/S架构下用户访问都是并发的，也就是说经常会出现同时N个用户对一个服务器页面发出请求。在这种情况下Word自动化调用会时常出现死进程。2. 由于隐藏界面运行，一些涉及界面的可以在窗口程序里成功调用的接口，在服务器端调用就会失败，甚至崩溃，这种情况也会经常导致死进程。3. 由于Word是复杂的桌面程序，并不符合一般Web服务程序简洁高效的标准，所以在服务器端运行时速度慢，并且还会消耗大量资源(CPU、内存)，尤其不能支持大量用户同时访问，资源会很快耗尽。
l 绝大部分开发者对COM技术比较陌生，在编程调用Word接口时经常存在一些代码错误，而又很难检查到问题所在，这又是导致死进程的经常因素。
Word死进程不仅会消耗服务器资源，还经常会导致服务器页面不能创建新的Word自动化对象而无法继续工作。有网友提出死进程解决方法：编程Kill掉Word死进程，这样是治标不治本的做法，Word死进程是不在了，可是Word非正常关闭会导致很多资源无法及时释放。这样的Web服务器能持续工作多久恐怕就很难说了。
既然在Web服务器端自动化调用Word存在这么多问题，那么能不能在客户端浏览器里调用Word呢？用JavaScript肯定可以，不过要想运行就得把浏览器的安全性降到最低，呵呵，恐怕没有几个用户愿意这么做啊。即使不存在安全问题，本来写在服务器端的代码逻辑要写在JavaScript里，由此带来的大量麻烦（打开、传值、取值、保存到服务器等）也会让人难以容忍。
4. 解决方案
为了解决这些问题，笔者经过全面研究比较，发现网上有一款软件SOAOffice（微软Office专用Web中间件），完全消除了以上问题，推荐给大家分享。
经研究发现，SOAOffice是一套由服务器端组件和客户端控件构成的中间件系统。服务器端组件是标准.NET组件，提供简洁高效的Word、Excel简化接口；客户端控件在浏览器网页里运行。服务器端调用SOAWord.WebOpen打开文档后，浏览器页面里客户端控件会启动客户机上的Word并且运行在网页里而不是本地打开。服务器端无需安装Office软件。
SOAOffice的架构很巧妙，开发者只需关注服务器端编程逻辑，客户端如何工作都交由控件自动完成。SOAOffice充分利用了分布式计算的思想，把本来要在服务器端运行的Word运算量交给了客户机。也就是说，原来采用服务器端自动化技术的网页同时要处理N个Word任务现在交给了N个客户机，每个客户机运行一个Word。服务器只需处理需要服务器处理的业务逻辑，一切与界面有关、与Word程序本身有关的工作由客户机运行，当然这也是客户机的强项。

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