将应用程序从Microsoft Access迁移到VB或C＃.NET

Question

我目前正试图说服管理层需要将我们的一个应用程序移植到.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中完成。

Answer 1

Answer 2

而不是告诉你它有多难 - 我相信你已经意识到了 - 我会试着抛出一些提示：

1）首先将您可以从MS Access中移出的所有内容移至MS SQL中。这意味着表，存储过程，视图等。如果您正确地执行此步骤，您的MS Access应用程序将成为真实数据库的前端，这已经是一个胜利。

2）在开始之前考虑放弃。可能更有意义的是识别哪些功能可以单独使用，而新功能可以获得WCF或MVC前端。

3）从VBA移植到VB.NET很有吸引力，理论上它更相似，但我不建议这样做。

Answer 3

我在部门工作，主要负责用.NET解决方案替换旧的Access应用程序。在我的公司中，Access应用程序用于简单场景，以满足单个员工或小组员工的业务需求。

有时Access应用程序增长，用户组增长或需要进行太多更改。在这种情况下，使用该Access应用程序的部门可以启动项目来重新创建应用程序。当这开始时，我们可以确定新应用程序将远离当前的Access应用程序。

首先，业务分析师被分配到项目中。他的职责是绘制当前的解决方案，并讨论当前解决方案的问题和对新解决方案的期望。我还没有看到“客户”只想更换当前解决方案的项目。每次客户还想要一些在Access中无法实现的新功能和扩展。

业务分析师创建了一些预期解决方案的初步描述，并将其传递给架构师。架构师决定将构建哪种类型的应用程序，需要什么类型的硬件基础架构以及应用程序如何连接到其他系统（如果需要）。在此初始阶段之后，IT对应用程序和所需的更改有了全面的了解。这里进行了一些初步估算，以便计划项目并分配资源。这个估计是项目的边界。比我的团队开始做这项工作。

我们正在使用敏捷方法，因此我们的客户（内部团队）会逐步看到应用程序中的新功能。首先，我们收集一些用户故事的初始集（积压）（特殊要求形式），我们估计这些用户故事，并让客户优先考虑它们。我们选择用户故事的子集进行迭代（通常为2-4周）。可以随时将新用户故事添加到待办事项，但我们选择的用户故事在迭代期间无法更改。在迭代之后，我们呈现客户工作的软件部分。根据工作部分，客户可以决定更改积压的优先级或创建新的用户故事。我们重复这种方法，直到客户说停止或单位预算被消耗。重要的是，并非所有用户故事都必须完成。项目计划有一些预算，一些低优先级的用户故事不必超车。

从技术角度来看，除了少数差异之外，它与其他任何项目一样：

• 您拥有初始数据库，并且您始终必须确保新解决方案中已实现的部分还具有现有数据的工作迁移。
• 您有现有的用户界面。用户可以喜欢或可以讨厌用户界面。确保您了解它，以便创建不比现有UI差的UI。我创建了UI必须完全不同的应用程序，并创建了UI必须完全相同的应用程序，以便用户不需要额外的培训。
• 尝试添加一些新功能，以便新应用程序合理。如果您可以描述新的所需功能，则更容易解释新应用程序的需求。

Answer 4

根据任何标准，650个表格/子表格都很大。这代表了一个重要的转换项目，而“缓慢”的端口将是一场噩梦。

我建议开发一个新的.NET应用程序“spike”，它包含绝对必需的基本功能，然后构建它。同时，从所有必要的修复程序中冻结Access应用程序。

有一些工具可以将MS Access表单转换为.NET，但它们可能会在具有子表单的复杂表单上失败。

'Effortlessly' Convert Access Forms to VB Objects

Answer 5

因此，如果用户在Access中并且他们采取操作来打开恰好是用C＃编写的不同可执行文件的表单，那么它“看起来”不会是同一个应用程序吗？

必须有一个用户组，他们喜欢一个只有他们使用的5-10个表单的独立应用程序。

摆脱未使用的表格/表单/功能是功能的增加。我不知道这个应用程序的文档级别，但从那里开始。当用户发现他们必须记录应用程序的区域并证明他们不需要使用的部件的合理性时，他们会自愿将其删除。