ms-access - MS Access 编程概述

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

1年前关闭。




Improve this question




我是一名 Java EE 开发人员，刚刚有人联系我，他希望我为他的业务应用程序提供报价，该应用程序可以与他们的 MS Access“后端”集成。

我希望发布这篇文章，只是获得有关 MS Access 编程最佳实践的一般高级概述。我假设该程序将完全在 VB 中，但不知道我是否可以选择在 VB.NET 或(最好)C# 中编写一些东西。

另外，我鄙视表示层:Access 应用程序有什么好的 GUI 构建器吗？

MS Access 程序员经常使用哪些常用工具和 API(单元测试框架、构建自动化系统等)？

您会推荐任何链接或资源吗？

这听起来像是一个非常简单的应用程序:获取输入的数据，将其与一些表格进行比较，然后将一些输出输出到屏幕上。我是一个相当不错的程序员，所以即使我从来没有做过 Access 程序，我也不会太难上手。

感谢您的任何想法或建议!

Answer 1

作为前端 Access
好吧，人们对 Access 有强烈的感觉。负面观点的主要原因是它被非开发人员广泛使用，他们没有适当的数据库开发概念，最终得到这些几乎无法工作、设计糟糕的应用程序，让开发人员感到恐惧。
话虽如此，Access 只不过是一种入门阈值非常低的快速应用程序开发工具。
好与坏
Access 是一个相当古老的产品线，跨越近 20 年。许多人反对 Access 作为一项技术的原因在于其早期历史:由于 Microsoft 认为向后兼容性很重要，因此 Access 多年来保留了其大部分功能，无论好坏。
您可以看到选择 VBA、非 winform 形式、通过 OOP 提升模块是糟糕的选择，但这些早期设计决策的连续性使 Access 成为一个稳定的平台。

VBA:是永不消亡的语言。它笨重、过时、缺乏语言方面的最新进展，但它也快速、易学、灵活、易于互操作(例如调用 Win32 API 非常简单)，并且可以与外部库(用 .网)。

绑定(bind)表单:默认情况下，Access 可以轻松创建工作应用程序，而无需一行代码。大多数查询也可以创建，而根本不必深入到 SQL。如果你是一个控制狂，这可能会很烦人，但很容易从那里开始编码和控制一切。

第三方集成:尽管 Access 有很多附加组件，但我不建议您使用大多数用户控件或第三方库，除非您确实必须这样做。在用户权限有限的环境中部署它们可能非常困难，并且版本控制可能变得很麻烦。

Ribbon:它可能是好是坏，这取决于你与谁交谈，但微软已经在这方面投入了大量资金，而且它可能会存在一段时间。至少 Access 2007 和更高版本中的功能区和改进的控件使应用程序的外观和行为以现代方式呈现。摆脱了旧的可怕 UI，您现在可以使用主题、HTML 布局和现代功能区做非常漂亮的事情。

可靠性
大多数反对意见，尤其是关于可靠性的反对意见，根本不再正确。
一个精心设计的Access Application 可以支持几十个并发用户。我有一个规模不错的应用程序，为一家拥有 150 个用户的制造公司管理采购/库存/质量/零件/项目，其中通常有 50 个在任何给定时间连接。我多年来没有任何腐败。
当然，您必须始终牢记 Access 是一个基于文件的多用户数据库，因此您不能指望它在网络不可靠或速度缓慢的环境中毫无风险地工作，并且通过 WiFi 连接到 Access 后端确实需要麻烦，就像您也不会通过无线处理大型 Excel 文件一样。
维护是应用程序生命周期的一部分。预防性维护非常重要。
不要等待出现问题:在您的应用程序中构建一些管理工具，以帮助检查您的数据状态(确保所有内容一致，检测无效的用户输入等)。
还要定期压缩数据库(作为后端服务器上日常自动化任务的一部分进行备份后，我每晚都进行压缩)。
一些随机提示

确保你的前端和后端是分开的:只有数据应该在后端，前端应该安装在每个用户的机器上。

从您的前端，打开一个指向数据库后端虚拟表的永久链接:保持始终在线的连接将大大提高性能。至于为什么，看看这个 question .

后端应该位于浅层网络共享中(不要将其放在多个目录下)。

确保您认真考虑如何将更新自动部署到所有客户端。
有很多方法可以做到这一点。我开发了自己的，但你可以使用 ClickOnce或 Tony Toews的 Auto-Front-End Updater

使用 Runtime :如果您在他们的机器上部署 Access Runtime，您的前端应用程序可以在没有用户干预其内部结构的情况下运行。它也是免费的。

不要与工具抗争:Access 有特定的做事方式。只需使用可用的工具，而无需编写代码，直到您用尽 RAD 环境的功能。您可能会惊讶于完全没有任何代码可以实现的目标。

没有什么能阻止您使用 OOP:定义类并将您的类手动绑定(bind)到您的表单、控制数据更新等。Access 中的默认行为倾向于鼓励快速开发并且适用于小型项目，但如果您怀疑您的项目可能成长，规划 future ，就像您使用任何其他框架一样。

作为后端数据库 Access
现在，如果您想使用用其他东西编写的前端，比如 C#，使用 Jet/ACE 驱动程序连接到 Access 后端数据库相当容易。

Jet 是 Access 的旧驱动程序，仅支持 .mdb文件。 Windows 中默认安装了 32 位驱动程序(在 Win8 中仍然存在)并且始终可以依赖。

ACE 是新的 .accdb Access2007/2010/2013 使用的格式。与旧版本相比，它增加了限制和增强功能，但它仍然可以与 .mdb 通信。 .
您必须安装 Microsoft Database Engine在所有客户端上(如果已经安装了完整版本或 Access 2007/2010/2013 运行时，则不需要)。

不要尝试使用 64 位版本的 Access/ACE 驱动程序。这是 future ，但它引入了许多新问题，特别是如果您使用 3rd 方库或您的某些客户安装了 32 位 Office(您无法混合和匹配 32 位和 64 位 Office 组件)。
同样，不要在 64 位模式下构建您的 C++/C#/Java/Python 前端应用程序，并期望 32 位 ACE 驱动程序能够工作。将所有内容保持在 32 位，让一切正常运行，然后在您确实需要时测试 64 位版本。

如上所述，请务必始终从您的代码中至少打开一个到后端数据库的连接。

理想情况下，尝试抽象任何特定于 Access 的代码，以便以后需要切换到基于服务器的数据库时更容易。您可以使用可以透明地与不同后端通信的 ORM，或者您至少可以将 SQL 查询分离到资源文件或以后可以轻松替换的单独对象中。

根据负载(主要是数据库中需要更改多少数据)，Access 后端可以轻松容纳 20-100 个用户而不会出现问题。如果一直发生大量插入和更新，事情就会恶化。有很多技巧可以用来使事情变得更好并使 Access 扩展性更好，但是您本质上受到正在构建的应用程序类型以及用户如何 Access 其数据的限制。