Question

我的客户要求我们基本上必须“解析”来自不同来源的PDF文件。

我们提供的解决方案，作为“第1阶段”（因为我们的上市时间很短，并且会节省大量时间）

1）手动使用Able2Extract应用程序从PDF文件中提取所需的列，并吐出Excel文件。这个excel文件仍然非常“脏”，因为它包含大量的头信息，我们不需要的额外字段等等。

2）运行我们的应用程序，将这个excel文件提供给它，它将执行剩余的清理工作。它需要这个“脏”的Excel文件然后给它们一个非常干净的excel文件，它只有3或4列，它们需要非常整齐地排列。

我们正在探索的第一个解决方案是在步骤2中使用VBA / Excel。他们将他们的脏输出，粘贴到Excel中，然后运行我们的清理宏。 Excel非常适合这种类型的东西 - 转移和清理Excel电子表格中已有的数据。我们用一个特定的“源”文件做了概念验证，结果很棒。花了大约半天的时间来制作这个'擦洗剧本'......

够简单吧？并不是的。此脚本仅适用于来自一个特定源的特定文件类型。我们将有10个不同的源，每个源可能有3-10种不同的文件类型。这意味着最终，我们可能会得到一个巨大的Excel宏，其中包含120个非常具体的“擦洗脚本”。所以我担心的是长期可维护性。我们也可能碰到我们以前从未见过的文件，这些文件可能会“破坏”我们的清理脚本，并且必须快速重新执行/更改为清理脚本...我从未使用Visual Studio Tools for Office并且使用VBA Excel宏的经验很少 - 但似乎这可能是一个很好的例子。

任何可能曾经做过类似事情的人的智慧之词？巨大的VBA宏是否会像噩梦一样维持？ VSTFO是一个很好的选择，它会给我“易于转移/擦除数据”的功能，但具有可扩展性和健壮性吗？老实说;我的第一个本能是一个纯粹的.NET解决方案，使用我们的Syncfusion Excel API从数据库中提取动态编译的脚本来进行清理/擦洗......但是这可能是一种过度杀伤......

感谢您的任何建议......

Answer 1

VBA比VSTO更容易处理。好吧，VBA可能不是一个很好用的语言，但至少它提供了对Excel对象模型的金属访问。基于VBA的解决方案可能比基于VSTO的解决方案更加更多稳定。

我会说VBA，如果你担心可维护性，可以考虑将“清理脚本”存储在不同的文件中。你可以

（a）每个清理脚本都有一个Excel文件，每个文件都有一个具有相同名称的宏;您的加载项可以为任何给定的输入文件加载（并执行代码）相应的Excel文件

（b）每个清理脚本都有一个文本文件，每个脚本都包含与上面相同的宏文本;您的加载项可以在运行时创建将其作为新模块导入 - 无论是自身还是临时工作簿。这样效率较低，但在版本控制系统中效果更好，因为您可以在文本文件的版本之间进行区分，但在两个Excel工作簿中区分模块并不容易。

在这两种情况下，您都可以将清理脚本存储在共享文件夹中，以便在需要修改脚本时进行集中更新。

Answer 2

我喜欢用C＃编程，但我讨厌VSTO。

我遇到的两个主要问题：。

你已经没有对代码的实时访问了，它全部编译成附加到工作簿的DLL，没有随时调试（这对于小RAD片段非常有用））。在使用Excel VBA时，通过Visual Studio进行调试不能替代任何地方进行调试。
您使用的是用于.NET使用的Excel VBA界面，而不是感觉原生的东西。你有像sheet.get_Range("A1:B1", System.Type.Missing);那样可怕的函数调用，而Missing代替了可选参数。

有很多人使用VSTO，但在Excel VBA平台上花了很多年，我发现此时迁移的原因很少。但是考虑一下你是否需要在C＃/ .NET中做一些非常酷的东西，你不能在VBA中完成（例如反射）。

你可以在VBA中编写非常好的代码;它会受到很多糟糕的压力，因为这是一个不会因为编写错误代码而惩罚你的环境，绝对任何人都可以使用VBA。

这些可能只是一个脾气暴躁的开发人员的抱怨，他对VBA而不是VSTO很有经验。所以说了这些 - 如果你不熟悉VBA，你最好直接去VSTO。我不确定微软打算如何处理VBA的问题; VSTO应该是未来。

Answer 3

首先，无论如何，你都需要'n'擦洗程序。事实上，Excel / VBA对于维护此功能并不比许多其他平台差得多。

您可以使用Userform添加界面，或者播放自动检测游戏，吐出任何不理解的“新”文件格式。还有一些强大的错误处理方案，因此无需担心事情会被破坏。

One Oil公司支付我使用4个Userforms和5000多行VBA编写Excel应用程序作为工具，以协助其会计师每月进行合资报告。该应用程序在其使用寿命结束后使用了4年，因为界面非常熟悉且易于使用。

...很抱歉对这个问题喋喋不休，但是有一种倾向于“俯视”VBA，因为很少有“真正的程序员”使用它......

Answer 4

我在Excel中编写了许多VBA函数，其中一些函数变得非常庞大和复杂。我不认为维护它们比处理任何其他大型项目困难得多，除非在人们不了解VBA的情况下。 VBA为您提供了许多方法，其中大部分都不是最佳方式。例如，如果你不是很小心，你会有很多看起来像

的代码

Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Value = "Test"
Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Font.Bold = True
Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Font.Italics = True

它应该是什么样的

With Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1))
  .Value = "Test"
   With .Font
      .Bold = True
      .italics = True
   End With
End With

两者都会做同样的事情，但第二个应该是一个稍微好一点的表演者（可能有更好的例子）并且至少在我看来更容易维持。

话虽如此，如果你和你的团队有经验写好VBA代码，那么我认为这是去这里的方法。否则，为了长期可维护性，我会考虑一个您有更多经验的解决方案。

Answer 5

我不会写任何需要VBA长期可维护性的东西，但如果它的短期VBA会好的。

在性能方面，VBA略快于.NET，但是你失去了很多不错的功能，并且VSTO新版本的抱怨，例如调试和完全OM访问都是过去的事情。

如果所有代码都纯粹用于Excel OM操作，我仍然会考虑使用VBA，因为它会稍微快一点并且没有使用.NET的明显优势（除了上面提到的团队熟悉程度之外）。 / p>

如果您正在使用其他库，那么使用.NET - 主要原因是您摆脱了需要在VBA中添加的十二个库依赖项，例如FSO，ADO，CDO等。

您听到的另一个常见抱怨是您必须使用C＃中的get访问器，并且必须使用Type.Missing。

使用较新版本的.NET，type.missing已成为过去。 get访问器问题只适用于互操作库的早期版本，我认为对C＃中范围对象和范围属性的使用有一个常见的误解。

我根本不必使用访问器方法，一旦为常用的Excel OM方法编写了一些包装器方法，您就不必编写缺少的参数。显然，.NET 4.0有更好的方法来解决这个问题。

Answer 6

我估计你应该和你的第一个叛徒一起去。

虽然从数据库中提取动态编译的脚本确实听起来有点过分。我可能不完全理解你的问题，因为我不确定从DB解决动态编译脚本的问题。

你已经有了Syncfusion Excel API，对于第2步，为什么不只是使用Syncfusion编写纯.net应用程序来加载和操作excel文件并重新保存它们。当您遇到支持更新应用程序并重新分发它的新文件类型时。

这个解决方案可能需要更长的时间来开发，但是：

将完全在.NET中（我讨厌VBA）。
不会将Excel用作服务器应用程序（另一张海报已经指出不是Excel构建要做的事情，MS建议反对它，因为其他海报提到的原因）。
Will（根据我的经验）比VSTO（互操作）和VBA也快一个数量级。

Answer 7

如果第2步最终需要成为一项服务，并且您愿意预先投入更多时间（取决于您的可交付时间表）和，那么您正在处理Open XML中的Excel（尽管可能）使用旧的二进制格式） - 查看Open XML SDK并查看Microsoft的recommended server side automation Office文档。

如果您需要快速交付，VBA将帮助您。如果您想要一些易于打包和分发的东西，VSTO将为您提供更多的努力。如果您需要服务，请完全寻找其他服务。

Answer 8

参考更广泛的问题，需要考虑的事项：

VBA IDE附带Excel。如果你想让更广泛的团队编辑代码，那么使用VSTO就不那么容易了。
现阶段有更多人知道如何写VBA而不是VSTO。
在此阶段为VBA提供更多在线支持。
VBA不仅仅适用于Office产品的自动化语言。它完全足够了，不会很快消失。 MS意识到这是Office对OpenOffice的影响之一 - 来自Accounts的Ken不会坐下来与Eclipse一起开始输入Public Static Void Main
一旦您想开始使用它，就像应用程序代码一样，VBA存在相当大的限制。仅包括类库是一种痛苦。如果这将广泛分发，我会选择VSTO。

正如上面所说的海报：5,000行代码是5,000行代码，给予或接受。

我不是VSTO的忠实粉丝。 VBA适用于它的目的。无需重写它。如果您需要获取硬代码，请使用C＃。

Answer 9

也许Microsoft Office SharePoint Server 2007/2010的Excel Services可能是什么？如果没有SharePoint，似乎不能使用Excel Services [look here]。

Excel Services 2007 - Overview

Excel Services 2007 - Architecture

Excel Services 2010 - Overview

Excel Services 2010 - Architecture

What Is Excel Services 2007?

架构Q - 适用于Office的VBA Excel宏或VS工具？

9 个答案: