如何将Ms Access应用程序转换为.Net应用程序的好方法？

Question

我们有一个12年历史的Ms Access应用程序，用于核心库存仓储和发票系统。虽然它已经在SQL Server后端运行，但所有“逻辑”，表单和报告都在Access中。在经历了将库存交易从非时间性转换为时间性所需的大量维护工作之后，我意识到我需要将这个东西转换成代码，以便在更可维护和可测试的环境中更好地管理逻辑。

有哪些技术可以让我以一种可管理和高效的方式将其转换为.Net应用程序？

一个想法是将查询转换为存储过程，然后将应用程序转换为Adp项目。但我仍然不知道如何处理表单和报告。

此外，我是我们公司唯一的开发人员，如果这很重要。

- Gilligan

Answer 1

简短回答：这种迁移似乎不容易自动化。

我猜你最好的选择是逐个重写（并安装）系统，即使这可能会迫使用户在一段时间内同时运行旧版本和新版本以使用不同的功能。您可以通过仔细考虑要迁移的功能和顺序来最小化这些麻烦。

例如，您可能有一个用户的工作角色要求他或她整天只使用一个屏幕。如果您首先迁移该屏幕并附带功能，则该用户可以立即使用新系统并且不再使用旧系统，从而减少您的维护负担。

所以这些只是基于不太多的信息的一些想法。无论如何，我希望这能帮助到你。

- catfood

Answer 2

由于您已经拥有了一些asp.net业务逻辑，因此您可以将其作为Web服务（asmx文件）打开。搜索Microsoft Office Web Services Toolkit以获取您版本的Access（xp / 2003等），它将为您编写VBA代理类来调用Web服务。您可以通过代码（VBA读写控件）将Web服务数据绑定到表单，或者使用来自Web服务的数据创建本地临时表并使用常规访问绑定。根据您最熟悉的内容（代码/ TSQL），您可以将逻辑放在存储过程中或放在业务逻辑层中或混合使用（两者都）。我发现测试代码比测试存储过程更容易，并且不喜欢将业务逻辑绑定到SQL Server，即如果您想要更改数据库或者想要离线开发/测试组件而没有数据库。新的.NET功能，例如LINQ具有相当好的性能，因此您不必依赖存储过程进行数据库活动。

保留访问前端用户界面，直到您将所有业务逻辑/数据访问重构为Web服务。 然后可以创建一个消耗Web服务的asp.net应用程序，或者如果需要的话，可以创建一个WinForm应用程序。(在此期间要避免使用WPF作为UI，因为它是一个陡峭的学习曲线，并且还没有与访问数据表视图相匹配的数据网格。)

报告：

访问报告可以升级到SQL Server Reporting Services（报告中的VBA不会升级，最好在存储过程中编写一些T-SQL）。 如果您没有完整的SQL Server产品，则仍然可以使用ReportViewer控件编写报告（请参见http://www.gotreportviewer.com/），绑定到ADO.NET数据集的asp.net（或使用Visual Studio标准版或更高版本中的winform）。 其他选项： 您可以编写.NET DLL并使用COM互操作性。这种方法允许您逐步开始编写功能。不要使用.NET UI，例如Winform，因为它无法与Access UI协调良好。您可以编写业务逻辑或数据访问逻辑，然后从VBA调用这些类。然后，如果需要，可以将此代码移动到ASP.NET或Web服务中。 排除的事项： 我不喜欢编写具有并排版本的新应用程序的方法。作为单个开发人员，您已经有足够的烦恼了。您可能最终会在两个版本中添加功能并调试两个版本而不是一个版本。

VB6表单Interop无法用于Access。

如所述，ADP相当死亡。（我从来没有喜欢过它们，因为我经常使用本地表来优化性能，它们只能通过代码调用而不能链接）

你可以使用Visual Studio中的Visual Basic升级向导将vba模块和类模块转换为vb.net，但它不能将所有内容升级（例如dao/ado代码到ado.net代码），并且不会创建针对.net优化的代码，根据vba代码的设计，可能不容易编写单元测试。我建议重新编写代码（如果你认真考虑测试，请尝试测试驱动开发来查看是否喜欢它）。

- Simmo

---

是的，我专门使用测试驱动开发（慢慢地将我们混乱的网站控制起来）。我很高兴听到报告转换的消息，并且我喜欢使用com interop思路来至少控制复杂部分。 - Gilligan

Answer 3

我会考虑查看Interop Forms Toolkit。据我了解，这个工具使得在VB6中使用.NET表单非常容易，因此也许可以在Microsoft Access中使用它？如果是这样，它可能有助于您逐步将应用程序迁移到.NET。我快速搜索了一下，未能找到任何关于在Microsoft Access中使用它的指南，如果这是一个死胡同，我很抱歉。

- Paul Batum

Answer 4

将其转换为adp在长期内不是一个好的解决方案 - 这项技术已被微软废弃。

如果您想要切换到.net（为什么？您有喜欢.net的理由吗？），我建议您开始阅读一些材料，尝试创建一些简单的应用程序，然后再开始将这个数据库转换为应用程序的任务。

但是...

我认为您和公司需要考虑此项目涉及的风险。如果您生病了，而管理层需要一些不存在的报告，那会发生什么？我建议您寻找一家小型本地软件开发公司，他们很乐意帮助您。也许您可以安排自己继续担任“首席开发人员”，只使用他们作为备份。

- birger

---

有趣的想法。我会选择 .Net，因为我已经在维护我们的网站，它是用 Asp.Net 构建的。因此，我实质上将库存系统中的业务逻辑集成到我们当前的基础设施中。某些业务逻辑已经在两个地方都重复了。 - Gilligan

Answer 5

我有一个类似的问题，并通过在Access前端创建一个版本化的部署系统（抓取和提取CAB文件），找出所需的AppDomain操作，以便将正确的CLR版本加载到Access进程中，加载.config文件并进行双向数据传输来解决它。

它使用标准的C DLL调用，因此不需要COM注册，但也不支持Unicode。

发送命令 - 通用，我可以用它做任何事情。 打开表单 - 旨在成为DoCmd.OpenForm的“插入”替代品 打开报告 - 旨在成为DoCmd.OpenReport的“插入”替代品

因此，创建一个新报告或将现有报告迁移到SSRS，使格式标准化，然后在Access中将DoCmd.OpenReport更改为netDoCmd.OpenReport。

遵循一种命名约定以了解要从哪里加载报告，并使用标准方法获取报告所需的数据。

现在，我正在根据容量的允许迁移一个表单或报告，或者当请求对其进行更改时。

因为谁能停止一年的功能开发来一次性完成所有工作呢？

但是MDI无法正常工作。我认为我仍然需要围绕SetParent和UPDATE_UISTYLE做一些工作。

所有这些都使得UI在进程和窗口中与Access一起运行。我将所有内容都构建在DLL中，最后一步是创建一个EXE，加载“第一个表单”，并使用它来替换Access前端。

- Roger Willcocks