我目前正试图说服管理层需要将我们的一个应用程序移植到.NET.该应用程序已成为Access(SQL中的后端)中的一个怪物,具有700个链接表,650个表单/子表单,130个模块和850个查询.
我非常了解这样做的所有主要好处,但现在需要了解如何在技术上实现这一点,因此我可以将项目计划放在一起.
所以,我的计划是将查询转换为后端的存储过程和/或视图,并在WPF或WinForms中重写表单.
现在,代码是我解开的地方.是否有可能将代码打包并将模块打包到dll中并在将它们慢慢移植到VB/C#时使用它们？
我们不能留下的是VB/C#中的一半应用程序和Access中的一半应用程序,它必须"出现"所有应用程序,甚至是迁移的一半.
提前致谢.
编辑:更多关于我们做什么以及为什么我们正在考虑远离Access的信息.
我们本质上是一个ISV,Access应用程序是我们的主要产品.该应用程序已经开发了15年,由许多开发人员临时开发.此应用程序没有文档.
我们在SCC中使分支机构正常工作时也存在问题,因此我们目前为我们拥有的六个客户端提供了4或5个代码库.最重要的是,我们所做的所有测试都是完全手动的,您可以想象这是非常耗费人力的,而且只是划分了真正需要测试的内容.
我们目前正在寻求扩展,并且拥有一些处于最后阶段的销售线索.我担心,随着这些新的销售,我们将被支持和测试淹没,而且这个应用程序将变得更加纠结于一辆车.
我还要补充一点,即我们即将进入一个全新产品的规格阶段,这几乎肯定是用.NET构建的.如果我们要在.NET中重写Access应用程序,那么我们用于此的人可以直接进入这个新的开发.如果我们留在Access中,那么我们必须得到一些新的Access人员,一旦我们开始新的开发,他们将不得不接受再培训.
所以基本上它已经归结为两种选择,在Access中进行主要的重构工作以尝试并"更好地"组织代码,而那些建议剔除部件的人最有可能是正确的; 我确定有些部件不再使用.但是,我担心如果我们留在Access,我们仍然无法建立有效的测试,我们仍然没有适当的SCC分支,这将导致支持继续成为一场噩梦,以及任何未来的发展产品料更糟糕.无论哪种方式,我们即将开始进行大量工作,这要么是在Acces中完成的,要么是在.NET中完成的.