我们有一个12岁的Ms Access应用程序,我们将其用于我们的核心库存仓库和发票系统.它已经在SQL Server后端运行,但所有"逻辑",表单和报告都在Access中.在经历了大量的维护污泥之后,它将库存交易从非时间转变为时间,我意识到有一天我需要将这个东西转换为代码,这样我就可以在更加可维护和可测试的环境中更好地管理逻辑.
有哪些技术可以让我以可管理和有效的方式将其转换为.Net应用程序?
一个想法是将查询转换为存储过程,然后将应用程序转换为Adp项目.但我仍然对如何处理表单和报告一无所知.
另外,如果重要的话,我是我公司的唯一开发人员.
简短回答:迁移似乎不容易实现自动化.
我的猜测是你最好的选择是一次一个地重写(并安装)系统,即使(也许)它强迫你的用户并排运行新旧版本一段时间使用不同的位功能.通过仔细考虑要迁移的功能和顺序,可以最大限度地减少麻烦.
例如,您可能有一个用户的工作角色要求他或她整天只使用一个屏幕.如果您首先使用附带的功能迁移该屏幕,则该用户可以立即使用新系统并将旧屏幕留在后面,从而减少维护负担.
所以这些只是基于不太多信息的一些想法.无论如何,我希望这有所帮助.
由于您已经拥有一些带有一些业务逻辑的asp.net,您可以将其打开以作为Web服务(asmx文件)进行访问.Google为您的访问版本(xp/2003等)提供Microsoft Office Web Services Toolkit,这将为您编写vba代理类以便调用Web服务.您可以通过代码将Web服务数据绑定到表单(vba以读取和写入控件),或者使用来自Web服务的数据创建本地临时表并使用常规访问绑定.
根据您最熟悉的内容(code/tsql),您可以将逻辑放在存储过程或业务逻辑层或混合(两者)中.我发现测试代码比存储过程更容易,比如没有绑定到业务逻辑的sql server,即如果你想要更改数据库或者想要在没有数据库的情况下离线开发/测试组件.LINQ等新的.net功能具有相当好的性能,因此您不必依赖存储过程来进行数据库活动.
保留访问前端用户界面,直到您重构了对Web服务的所有业务逻辑/数据访问.然后,您可以根据需要创建一个使用Web服务或winform应用程序的asp.net应用程序.(暂时忽略wpf,作为一个ui,因为它是一个陡峭的学习曲线,并且还没有可以与访问数据表视图进行比较的数据网格.)
报告
访问报告可以升迁到sql server报告服务(报告中的vba不会升迁,最好在存储过程中编写一些tsql).如果您没有完整的sql server产品,您仍然可以使用reportviewer控件在asp.net中编写报告(请参阅http://www.gotreportviewer.com/)(或使用标准版或更高版本的winform Studio)绑定到ado.net数据集.
其他选项: 你可以编写.net dll并使用com interop.这种方法允许您逐步开始编写功能.不要使用.net ui,例如winform,因为它不能很好地访问ui.您可以编写业务逻辑或数据访问逻辑,然后从vba调用这些类.如果需要,您可以将此代码移动到asp.net或Web服务.
要排除的事情:
我不喜欢用并排版本编写新应用程序的方法.作为一名开发人员,您有足够的担心.您可能最终会在两个版本中添加功能并调试两个版本而不是一个版本.
vb6表单interop不适用于访问.
如上所述,ADP已经死了.(我从不喜欢它们,因为我经常使用本地表来优化性能,它们只能通过代码调用而不是链接)
您可以使用Visual Basic升级向导(在visual studio中)将您的vba模块和类模块转换为vb.net,但它不会升级所有内容(例如dao/ado代码到ado.net代码),而不是创建针对.net优化的代码,根据vba代码的设计,可能不容易编写单元测试.我建议重写代码(如果你认真测试是否喜欢它,请尝试测试驱动开发).