VBA中更大项目的缺点

Question

我是在Access 97中基于Visual Basic for Applications（VBA）的具有更大企业/会计系统的公司项目的新手。这个应用程序仍然存在，它们进行更新，一切都工作得相对较好。但他们希望将此应用程序移至最高级别，加快开发速度，使这个应用程序对最终用户更具“吸引力”等等。但如果继续开发使用此技术（VBA）是个好主意我不会感到害羞因此 我有几个问题。如果你能帮助我，我会很高兴。

1. VBA甚至是为更大的项目而设计的吗？我认为，它更可能是宏和简单的功能，扩展了Access功能。
2. 将应用程序转换为.NET winforms / wpf
会更好
3. 可以为VBA项目开发更多开发人员吗？
4. 针对独立应用程序托管程序中运行的VBA代码的最大缺点是什么？
5. 可以运行单元测试或任何类似的技术吗？

非常感谢您的回复

编辑： Access接口现在几乎使用SQL Server，但这不会改变主要问题。

Answer 1

非常主观。 VBA的声誉很差，但这只是因为它被设计成一种非常易于访问的脚本语言，适合那些没有很多技能的程序员。对于大型项目使用类似语言的最终讽刺是，它需要一个非常熟练的程序员不要让它失控。就像有人在语言不支持命名空间时理解你必须要做的事情一样，你最好从一开始就提出一个非常好的命名约定。

我猜你为什么问这个问题。答案是，仅仅因为语言没有吸引力而抛弃多年的工作是极其困难的。这方面的代号是Netscape 6.0版，Spolsky的“T hings You Should Never Do”很好地覆盖了它。

发现你为拥有棕色领域产品的雇主工作的最佳方法是寻找另一种产品。

Answer 2

对于那些展示Access丰富经验的人来说，这里没有真正的答案，所以我会给出答案：

  

1 VBA是否设计为更大   项目？

定义“更大的项目”。一般来说，我会说不，但我正在考虑企业范围的应用程序。但问题不在于是否可以使用VBA，而是Access是否适合这种程度的应用程序。 Access的最大缺点（除了表单部署问题）是管理项目，因为源代码控制并不像其他开发平台那么容易。

但是你并没有真正了解应用程序有多大。数百人使用它吗？或者它只有几百个子组件？也就是说，它在复杂性方面还是在用户数量方面都很大？

  

我认为，它更多   很可能是宏和功能   它扩展了Access功能。

正如我所说，你问的是错误的问题。问题在于Access是否是一个合适的前端。如果是，则VBA是您必须编写的语言。

对于“宏和简单函数”，存在一个术语问题，即在VBA中生成Word和Excel“宏”，这使得许多人认为VBA是一种简单的语言。 VBA实际上是VB6的SUPERSET（不是子集） - VBA内置了比VB6本身更多的功能。使用Access，大多数功能都特定于与数据库交互，因此非常有用（例如，将Access绑定表单与VB表单进行比较）。

但是，一般而言，Access哲学是指以交互方式构建对象，点击式开始，然后仅在默认行为不足时添加代码的哲学。 VBA具有很大的灵活性，因为它可以与任何具有COM接口的工具进行交互。它的功能基本上是无限的（尽管实际上存在限制）。

  

2将应用程序转换为.NET winforms / wpf

会更好

“更好”的目的是什么？如果你有一个有效的应用程序，你真的必须考虑Spolsky / Netscape效果（如上所述）。当然，您可能会获得更好的代码管理，但代价是必须保持更多的代码管理。另一方面，如果您在该开发平台上拥有内部专业知识而VBA没有内部专业知识，那么将倾向于迁移到更适合您的特定开发人员的开发平台。

但这不是一个“更好”的问题，如果不了解所涉及的所有问题和人员，就无法真正确定。

  

3可以为VBA项目开发更多开发人员吗？

使用Visual SourceSafe，您可以让多个开发人员处理该项目。或者，您可以使用Application.SaveAsText / .LoadFromText自动化构建，并使用您选择的CVS。

但总的来说，我认为Access更适合单一开发人员模式。

  

4托管程序中运行的VBA代码的最大缺点是什么？   反对独立申请？

我不知道这个问题意味着什么。许多人都有一个疯狂的想法，即Access前端的工作集比VB6应用程序的工作集要大，但事实并非如此。我希望.NET大致相同（如果不是更大的工作集，因为随着“进步”前进，事情总会变得越来越大）。

在我的选择中，Access的最大缺点是部署问题，任何需要多个Access版本的用户都会遇到很多问题。 SageKey安装脚本旨在解决这个问题，但它们是临时性的 - 它们会在出现时解决问题，因此如果您的部署环境存在问题但尚未遇到和处理，那么您就不会运气。但他们确实涵盖了大多数此类情况。

  

5是否可以运行单元测试或任何类似技术？

我不相信，但是作为Access开发人员，我可能不知道单元测试到底是什么。大多数Access应用程序的代码都是用户界面，而不是算法编程，所以我认为它不容易测试。这是否是一个问题取决于项目的性质和被认为必要的测试类型。

对于一个会计应用程序，你确实需要高水平的可靠性，正如我在其他地方的评论中所说，如果有人采访了我建立会计应用程序的潜在项目，我建议他们不要从无论选择何种平台，都要划伤。

Answer 3

1. 理论上没有 - 它主要是为少量用户的应用而设计的。您的示例显示它可用于较大的项目。
2. 生成的系统（如果转换正确）将具有更好的质量。但是，与业务一样，您必须考虑转换成本。
3. 是的，他们可以，但更难，因为没有多少与Access模块​​兼容的源控制系统（Beyond Compare应该可以工作，而且还可以）。
4. 性能，可扩展性等等。我认为没有优势，只是VBA对大型系统并不是很好（想象一下你想要一些网络报告，或者其他功能对于Access非常困难）
5. 这是可能的 - 但完全手动

与所有技术一样，使用Access几乎可以实现一切 - 但您必须考虑维护此类系统的成本。这不是一个问题，如果你将转换，但你必须。

Answer 4

您可能需要先向公司提出几个问题：

• 为什么项目没有迁移到新版本？保持一个版本意味着想要长期杀死该项目。如果不值得跟上当前版本，可能还没有足够的资源来正确维护应用程序。这很可能会破坏迁移轨迹。不得不弥补10年的维护不足是很昂贵的。
• 10年前就像现在一样，在VBA中建立一个大型系统是一个坏主意。你为什么要相信管理层现在会做出更好的决定呢？
• 处理此类遗产的正确方法是确保维护人员在您停止使用该软件几个月后达到退休年龄。管理层何时会发生这种情况？获得合格人员将变得越来越困难，技术越来越过时。
• 迁移这些类型的系统可能非常昂贵。当他们不愿意提前投资时，管理层是否愿意现在进行投资？您需要制定一个策略，您可以采取非常小的步骤并使用新编写的软件。不要使用普通的.net / winforms / wpf。确保您花费一些时间来寻找至少一个应用程序级框架。一种完全不同的方法是使用MOOSE之类的工具来重新设计解决方案。

Answer 5

嗯，根据他们在90年代后期的受欢迎程度，在VBA中找到应用程序是正常的。感谢新的MS框架，如果您愿意，.Net允许您将代码从VBA转换为VB.Net。

当你说VB今天可以在Excel的宏中使用时，你是对的，但对于一个大型项目，如果你想与Web服务和你可以拥有的所有新功能进行交互，VBA可能会受到限制在.Net。

最大的挑战是能够修复可能出现的转换错误。如果您的VBA项目已在模块或表格集中开发，则应进行每个元素的转换并验证转换是否正常运行。

通过转换的项目，许多开发人员可以使用projet，不仅使用VB.net，还使用.Net框架的其他语言。此时，Web Services，NHiberante作为持久性API，NUnit作为单元测试（许多其他功能）可以添加到更新的项目中。

这是转换时带有MSDN信息的链接。 http://msdn.microsoft.com/en-us/library/aa192490(v=office.11).aspx

Answer 6

1. 几乎每个人都有一个VBA恐怖故事，其中一个访问或Excel应用程序在大规模环境中运行，但正如ufoq所说，在某些时候你将不得不进行切换。是否必然导致问题的VBA，或者是Access运行的Jet引擎？访问GUI可以在具有SQL Server后端的大型应用程序中使用。

2.Most可能，虽然这显然取决于开发人员的技能。

3.这将是一个问题，因为每个人都会在同一个文件上工作。所以，是的，版本控制支持的gt开发对于更多的开发人员来说会更好

4和5.见ufoq的答案

Answer 7

1. 没有。它是Visual Basic for Applications，它就是这样，为COM对象和宏提供接口。

2. 我会开始转向WPF，因为这将是两种选择的未来证明，但是如果你的支持机器还没有运行XP Sp2，你将需要使用WinForms（尽管我非常怀疑这种情况）。对于Microsoft.VisualBasic命名空间中所有有用的dodad，VB.Net可能是一个很好的起点。

3. 是的，开始将解决方案分解为单独的.vba和.mod文件并引入源代码管理。但是，到目前为止，您应该考虑将开发人员迁移到VB.Net或C＃。

4. VBA几乎停留在单线程执行上。与VB.Net和C＃结合使用时，Visual Studio Tools for Office缺少直接使用VBA的功能。

5. 排序。请参阅VBAUnit。

需要记住的是，VB6在2008年达到了临终状态，而VBA仍然包含在Office 2010中，但鼓励开发人员使用VSTA。管理员过去常常使用批处理文件和VBA脚本，但是Powershell正在缓慢但肯定地取代这种类型的实现。基本上，VBA仍然有效，但有更新的（可能更好的）做事方式（不会很快就会结束）。