我们拥有12年历史的Ms Access应用程序，可用于我们的核心库存仓储和发票系统。它已经在SQL Server后端上运行，但是所有"逻辑"，表单和报表都在Access中。在经历了将库存交易从非临时性变为临时性所花费的大量维护污泥之后，我意识到我有一天需要将其转换为代码，以便可以在更加可维护和可测试的环境中更好地管理逻辑。

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

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

另外，如果有关系的话，我是公司的唯一开发人员。

解决方案

简短的答案：迁移似乎不容易自动化。

我的猜测是，最好的选择是一次重写(并安装)系统一次，即使(也许)它迫使用户并排运行旧版本和新版本一段时间以使用不同的位功能。我们可以通过仔细考虑要迁移的功能和顺序来最大程度地减少麻烦。

例如，我们可能有一个用户，其工作角色要求他或者她整天只使用一个屏幕。如果首先迁移具有相关功能的屏幕，则该用户可以立即进入新系统，而将旧系统抛在后面，从而减少了维护负担。

因此，这些只是基于过多信息的一些想法。希望这对我们有所帮助。

我会考虑查看Interop Forms Toolkit。据我了解，此工具使从VB6内部使用.NET表单变得非常容易，因此也许也可以从Microsoft Access中使用它。如果是这样，它可以以增量方式将应用程序迁移到.NET。快速搜索后，我找不到与Microsoft Access一起使用它的任何指南，因此，如果这真是一条小巷，我深表歉意。

从长远来看，转换为adp并不是一个很好的解决方案，Microsoft放弃了该技术。

如果要切换到.net(为什么？为什么要支持.net？)，建议我们开始阅读一些内容，尝试创建一些简单的应用程序，然后开始将数据库转换为应用程序的任务。

但...

我认为我们和公司需要考虑该项目涉及的风险。如果我们生病了，就在管理层需要一些尚不存在的报告的那一周会发生什么？我建议我们寻找一家小型本地软件开发公司，他们将很乐意为我们提供帮助。也许我们可以安排我们继续成为"主要开发人员"，并且仅将其用于备份。

由于我们已经拥有具有某些业务逻辑的asp.net，因此可以打开它以作为Web服务(asmx文件)进行访问。适用于我们使用的访问版本(xp / 2003等)的Google for Microsoft Office Web服务工具包，它将为我们编写vba代理类，以供我们调用网络服务。我们可以通过代码(使用vba读取和写入控件)将Web服务数据绑定到表单，或者使用Web服务中的数据创建本地临时表并使用常规访问绑定。

根据我们最喜欢的东西(代码/ tsql)，可以将逻辑放入存储过程或者业务逻辑层或者混合逻辑(两者)中。我发现测试代码比存储过程更容易，并且就像不绑定到sql server上进行业务逻辑测试一样，即如果我们想更改数据库或者要在没有数据库的情况下离线开发/测试组件。诸如LINQ之类的.net新功能具有相当好的性能，因此我们不必依赖存储过程来进行数据库活动。

保留访问前端用户界面，直到重构了对Web服务的所有业务逻辑/数据访问。然后，我们可以创建使用Web服务的asp.net应用程序，也可以创建Winform应用程序(如果需要)。 (暂时不使用wpf，因为它是一个ui，因为它是一个陡峭的学习曲线，并且还没有可以与访问数据表视图进行比较的数据网格。)

报告书

可以将访问报告扩展为sql服务器报告服务(报告中的vba不会扩展，最好在存储过程中编写一些tsql)。如果我们没有完整的SQL Server产品，则仍可以使用reportviewer控件在asp.net(或者标准版或者更高版本的Visual的Winform)中编写报告(请参阅http://www.gotreportviewer.com/)。 Studio)绑定到ado.net数据集。

其他选项：
我们可以编写.net dll并使用com interop。这种方法使我们可以逐渐开始编写功能。不要使用.net ui，例如Winform，因为它不能与Access ui很好地配合使用。我们可以编写业务逻辑或者数据访问逻辑，然后从vba调用这些类。然后，可以根据需要将此代码移至asp.net或者Web服务。

排除的事情：

我不喜欢使用并行版本编写新应用程序的方法。作为一个开发人员，我们有足够的烦恼。我们可能最终会在两个版本中都添加功能并调试两个版本而不是一个版本。

vb6形式互操作不适用于访问。

如前所述，ADP已经死了。 (我从不喜欢它们，因为我经常使用本地表来优化性能，并且只能通过代码调用它们，而不能链接它们)

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