从VBA到VSTO的一些想法

最近学习了李永富老师的《VSTO开发入门教程》,跟之前的VBA知识对比下,有很多感触。

简单比较

说说VBA

VBA(Visual Basic for Application)是通过VB语言来操作OFFICE文档、程序以及其他软件产品的技术,使软件的用户扩展性理论上无穷大。

Office中VBA需要启用开发工具,即可录制宏,使用宏,插入模块等,非常的方便,尤其是自定义函数,不需要任何其他操作,只需要关心函数本身的逻辑,用户可以通过录制宏来学习任何操作的代码实现方法,极易成长。

但同时,VBE(Visual Basic Editor)(就是office自带的原生编辑器)真是上世纪九十年代既视感,习惯了IDEA这种强大的IDE的同学肯定感觉在记事本里面写代码一样。

聊聊VSTO

VSTO是一门新技术(相对于VBA)了,其实就是用.Net的形式来写Office程序。

当然了.Net不仅仅支持VB,也支持C#,这意味着,你既可以用熟悉的VB来写(忽略VB.NET和VBA细微的语法差异),也可以用更强大的C#来写,相比较而言,可以用C#来实现更复杂的需求,比如多线程,比如面向对象(真正的面向对象,VB更像是面向过程,不过支持面型对象而已)。

中间操作遇到一个问题,即VBA的方法,函数,C#中不一定有,或者使用方法与场景不同,这就是.Net的长处了,.Net是一门技术,不是一门语言,你可以直接在C#中使用VB的库,就像使用C#自己封装的库一样(比Java的JNI方便的不要不要的)

但是,需要装一个VS,具体版本取决于目标office程序,如我的office是2016,就需要装一个VS2017版本,大学时就体验过微软的豪华,现在装一次VS2017,真是有感触,豪华永无止境啊,上来就是10G+。不过宇宙级IDE总是对得起它的空间的。

话说回来,一个简单的文档操作,至于这么大动干戈吗? 
生命在于折腾!

其他操作方式

其实除了微软提倡和支持的VBA和VSTO两个方式外。其他很多编程语言都可以直接操作Office文档

因为Office文档本身就是一个xml文件,xml本身又是一个文本文档,或者说,只要能读写文件,处理字符串的变成语言,理论上都支持操作Office文档。

操作office文档本质就是操作一个复杂的XML文件,底层使用xml文档操作技术(如DOM,SAX)封装一些常用方法,属性,类库,呈现出来一个框架或是技术,成为这个编程语言操作Office的利器。

现在操作Office文档生态较好的语言有,JavaScript、Java、Python。

生态最好的当然是C#了。为什么有C#?它不是本身就支持吗?,C#除了使用VSTO技术操作Office文档外,还可以直接通过控制台或是Form或是Web项目using相关命名空间,即可直接操作Office。

既然有这么多语言可以支持,那为什么要用VS,要用C#.Net呢?

  • 兼容性 
    微软没有开放Office的API接口,其他语言类库是直接凭经验解析,很可能有些老版本,或是特殊一点的文件,又或者新文件解析出错,.Net原汤化原食。
  • 可扩展性 
    从数据区到功能区,到各种操作窗格,用户控件,真的是其他非MS系语言可以比拟的。
  • 学习成本 
    用户不需要整天去开着某个类库的官方文档来学习,想知道某个操作如何用代码实现,直接录制宏,查看宏代码(VB),文档对象模型都是大致相同的,然后用C#的方式实现,遇到问题,F1查看帮助。

工具推荐

VS可以直接使用最新版(现在是2017)的社区版本,免费且完全够用。

习惯IDEA或是(其他JB系列产品)的,可以装上ReShaper插件,使用IDEA快捷键和编辑方式。

习惯eclipse也可装上asEclipse,体验visual studio for eclipser

比较结论

小需求用VBA

毕竟轻量

大需求用VSTO

强大

文档级别需要自定义函数尽量用VBA

VBA简单,VSTO自定义函数过程太繁琐

文档级别不需要自定义函数用VSTO

不自定义函数,C#写起来就是比VB舒服(个人感觉)

外接程序界别用VSTO

这个不多说了,可以直接打包做成EXE给别人。

保证兼容性优先,使用VBA

大家都是盗版,拿什么保证客户机装了vsto for office

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页