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

【问题标题】：Migrating application from Microsoft Access to VB or C#.NET将应用程序从 Microsoft Access 迁移到 VB 或 C#.NET
【发布时间】：2011-04-08 09:48:26
【问题描述】：

我目前正试图说服管理层需要将我们的一个应用程序移植到 .NET。该应用程序在 Access（SQL 中的后端）中变得有点像怪物，有 700 个链接表、650 个表单/子表单、130 个模块和 850 个查询。

我几乎知道这样做的所有主要好处，但现在需要看看如何在技术上实现这一点，以便我可以制定项目计划。

因此，我的计划是将查询转换为后端的存储过程和/或视图，并在 WPF 或 WinForms 中重新编写表单。

现在，代码是我不解的地方。是否可以将背后的代码和模块打包成 dll 并在缓慢移植到 VB/C# 时使用它们？

我们不能只剩下 VB/C# 中的一半应用程序和 Access 中的一半应用程序，它必须“显示”为一个应用程序，即使是在迁移的一半。

提前致谢。

编辑：关于我们所做的事情以及我们为什么要离开 Access 的更多信息。

我们本质上是一家独立软件开发商，Access 应用程序是我们的主要产品。这个应用程序已经开发了 15 年，由许多开发人员临时开发。此应用程序没有文档。

在 SCC 中让分支正常工作方面也存在问题，因此我们目前有 4 或 5 个代码库供我们拥有的六个客户使用。最重要的是，我们所做的所有测试都是完全手动的，您可以想象这是非常劳动密集型的，并且只触及了真正需要测试的部分。

我们目前正在寻求扩展，并且有许多销售线索处于最后阶段。我担心随着这些新的销售，我们会被支持和测试所淹没，而且这个应用程序会变得更加纠缠不清。

我还要补充一点，我们即将进入一个全新产品的规范阶段，该产品几乎肯定会在 .NET 中构建。如果我们要在 .NET 中重写 Access 应用程序，那么我们使用的人可以直接进行这个新的开发。如果我们要留在 Access 中，那么我们必须让一些新的 Access 人员加入，一旦我们开始新的开发，就必须对他们进行再培训。

所以基本上它归结为两种选择，Access 中的主要重构工作以尝试更好地“组织”代码，而你们中那些建议剔除部分的人很可能是正确的；我敢肯定有些零件不再使用。但是，我担心如果我们留在 Access 中，我们仍然无法构建有效的测试，并且我们仍然不会有适当的 SCC 分支，这将导致支持继续成为一场噩梦，以及这方面的任何未来发展产品使事情变得更糟。无论哪种方式，我们都将开展大量工作，要么在 Acces 中完成，要么在 .NET 中完成。

【问题讨论】：

从 MS Access 中转义并不是那么容易。
700 个链接表听起来很可疑，就像有人在设计正确的数据模式方面没有做太多工作。正如@Albert D. Kallal 在下面的冗长回答中指出的那样，您最好先解决这个问题，否则 .NET 中的任何新开发都无法真正解决固有问题。
我不确定逃离许多应用程序有那么容易。尝试转换 700 个电子表格。

标签： c# vb.net ms-access migration

【解决方案1】：

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

我建议开发一个新的 .NET 应用程序“spike”，其中包含绝对需要的基本功能，然后在此基础上进行构建。同时，将 Access 应用程序从除基本修复之外的所有修复程序中冻结。

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

'Effortlessly' Convert Access Forms to VB Objects

【讨论】：

我同意你不要尝试移植整个东西的想法，但是在新平台上做新工作时保留旧功能不是更好吗？跨度>
@Steven Sudit：这就是我的建议（显然不够好！更新了...）
米奇，如果我理解正确的话，我们的建议不同的是，您建议先移植基本功能，然后再构建它。相比之下，我说最好只使用新工具构建新功能，迫使用户继续使用 MS Access 来完成现有任务。
米奇，在评论拉迪斯拉夫的回答时，我想我知道最大的不同是什么。您正在谈论用最初执行较少的 MS Access 应用程序替换 MS Access 应用程序。这很难卖。我建议一个做新事情的新应用程序，尽管涉及一些旧数据。这很容易推销，而且还可以将数据集中到 SQL Server 上。
我同意 650 个表格听起来很多。它向我暗示了大量重复，就像我在接管用户创建的 Access 应用程序时经常遇到的那样。非常常见的是使用不同的 Recordsource 多次保存相同的报表布局，而不是使用一个报表布局并在收集用户输入后在运行时分配 Recordsource。这也适用于表单，但根据我的经验，报告和查询比表单更常见。

【解决方案2】：

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

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

2) 在开始之前考虑放弃。与其移植所有内容，不如识别哪些功能可以单独保留，而新功能获得 WCF 或 MVC 前端可能更有意义。

3) 从 VBA 移植到 VB.NET 很诱人，理论上它更相似，但我不推荐这样做。

【讨论】：

+1。尽管我没有在回答中提到，但我之前已经走了（1）的路线，但后来申请就这样离开了；即 Access 前端和 SQL Server 后端，因为它运行良好，因此没有进一步升级。
@Mitch：一旦数据被解放出来，你就有更多的选择，包括混合和匹配 UI。问题是您通常必须首先将业务逻辑从 VBA 迁移到 T-SQL。
勇敢的回答。当心 ms-access 标签的 Darth Vaders。 meta.stackexchange.com/questions/51441/…
@Hans：我已经被两个 Darths 咬了，所以我知道你在说什么。幸运的是，我受到对我的 SO 号码的强烈冷漠的保护。 :-)
我还是不明白你的意思。后端已经是 SQL Server，你说“一旦数据被解放”，这向我表明你在谈论，嗯，数据，而不是应用程序。我不认为你对“解放”的断言有实际的理由，你只是想为说一些愚蠢的事情编造一个事后的理由。

【解决方案3】：

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

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

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

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

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

从技术的角度来看，它和其他项目一样，除了一些不同之处：

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

【讨论】：

优点：1）不要作为横向移动出售；总是提供新的功能。 2) 如果 Access 应用程序变得足够大，预计它们需要更换，并为此做好计划。 3) 您要替换的内容可能会在 UI 或 DB 方面出现问题，但您需要充分了解它才能继续满足业务需求。
“想要一些在 Access 中无法实现的新功能和扩展”，您可能的意思是“想要一些新功能和扩展，这些新功能和扩展无法由具有新手级别访问编程技能的用户在 Access 中实现。 "在 Access 中实际上不可能完成的事情真的很少。
我认为甚至考虑提出横向移动都是荒谬的——花掉所有的钱却没有改善的价值在哪里？我无法想象为什么任何部门会同意为任何提供的项目提供的服务远不超过他们现有的 Access 应用程序已经提供的服务，因此认为在港口对我来说似乎很可笑。
我们正在寻找的是能够有效支持和维护应用程序的巨大改进。
您是否曾尝试在增强支持和维护便利性的基础上推销完全横向移动？你不会得到买家。

【解决方案4】：

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

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

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

【讨论】：

这是一个非常好的观点。如果超过一半的对象是不再服务于任何目的的遗留对象，那么对于用户创建的应用程序这种大小的应用程序，我一点也不感到惊讶。在进行任何移植之前，第一步是剔除应用程序以删除多余且不再使用的内容，然后查看剩下的内容并查看可以再次减少多少（例如重复的报表布局有小的差异） .如果这样大小的应用程序中 3/4 的对象没有被此类评论完全消除，我不会感到惊讶。
我非常同意，我认为无论我们最终走哪条路，在开始编写文档之前都会进行筛选。

【解决方案5】：

我参与了许多迁移项目，其中一个是从一个平台转换到另一个平台。我还看到了惊人的成本超支，以及对这些类型项目的困难程度的惊人估计。

在我创建并花费大约 25,000 美元构建的一些项目和平台中，更换和重写此应用程序的成本导致其他团队接管该项目，由此产生的成本过高750,000 美元。

您还假设需要更换当前系统。您必须清楚地知道移动和替换当前平台和软件的实际目标是什么。简单地重写一些东西并将功能转移到另一个平台上几乎没有收益，除了花很多钱，这对你的业务没有任何好处（但是，嘿，那些开发人员会拿钱，如果他们说服你需要这样做）

您可能想阅读 Joel 撰写的这篇关于软件的精彩文章（顺便说一下，Joel 开发并创建了这个论坛堆栈溢出 - 我在他的一些讨论论坛中担任版主将近 10 年），。在这篇文章中，Joel 警告并警告不要突然重写不会生锈或磨损的完美软件。

你不应该做的事情，第一部分

乔尔·斯波尔斯基

他们做到了。他们犯了任何软件公司都可能犯的最严重的战略错误：

他们决定从头开始重写代码。

文章在这里：http://www.joelonsoftware.com/articles/fog0000000069.html

Joel 继续指出，在过去 10 年中，那篇文章仍然是他最受欢迎的文章之一（并且有些争议）

将一个运行良好且运行良好的应用程序运行了 10 年并完成其工作，然后简单地在另一个平台上重写它是没有意义的，特别是如果您没有可用的人力、专业知识和人员维护这个新系统。如果新系统不能完成比以前系统所做的更多的事情，情况尤其如此。事实上，如果你确实有那个 Manpower，他们很可能已经开始随着时间的推移转换这个系统。我的意思是为什么突然有人突然打开电灯开关，然后突然意识到需要引入新的开发人员来重写已经运行良好的系统？

我还要指出，我从事该行业已有很长时间（既是出版书籍的出版编辑，也是访问书籍的技术编辑），我还做过从大型机系统到台式机的迁移项目。而且，我还完成了桌面数据库系统向大型主机系统的迁移。

我只能说很少见有这么多表的应用程序。事实上，这个问题马上就敲响了警钟。

因为这里有这么多的表，我不得不认为可能有很多进程，多个应用程序在这里拼凑在一起，代表了整个系统。如果不是这种情况，那么在 .net 中重写当然没有意义，除非您解决系统的非规范化性质。数据已经在 SQL Server 中的事实有所帮助，但这可能意味着您有能力、容量和基础设施来扩展设计不佳的东西，并且放在首位

软件灵活性的很大一部分来自正确规范化的数据模型。您遇到的问题是您在 SQL Server 中有数据，并且很想将部分表单和功能重写为 .net 表单，并继续使用当前现有的数据模型。不幸的是，这使您陷入了困境，因为您想继续使用现有数据，并开始在 .net 中重写功能。然而，在 .net 中重写功能而不解决数据模型是一个非常糟糕的主意。

具有讽刺意味的是，这是一个陷阱 22，因为如果该系统具有非常出色的设计数据模型，您甚至可能不需要重新设计并将其移至 .net。 Access 和 SQL Server 可以轻松扩展到 100 位用户。并且，access 支持类对象的使用，甚至源代码控制。

换句话说，请记住，人们可能会要求在 .net 中重写它，因为他们相信应用程序会神奇地增加灵活性，并且能够比他们不断变化的业务规则更快地进行更改。事实上经常发生相反的情况，因为访问是一个非常 RAD 的工具。这意味着，由于业务规则的变化，一线人员经常可以进行修改，比 IT 部门和他们的开发人员团队在下一个伟大版本的应用程序上工作的速度更快。更糟糕的是，您不想让 IT 部门和那些数据模型不佳的开发人员陷入困境。

我的意思是，由于当前的业务流程不够灵活，您现在是否要聘请 IT 部门来构建每一个电子表格并为人们提供卓越的表现？如果 IT 部门绕到每个人的办公桌前，握住他们的手，为每个人正确地制作 Excel 表格，那就太好了，但这在现实世界中是不切实际的。因此，除了从这些人手中夺走访问权限之外，您还不如从他们那里夺走 excel。

我只是指出，我的蜘蛛感告诉我，这里的数据模型将是一个真正的挑战。请记住，我总是会反过来使用糟糕的代码和设计出色的数据模型（很棒的代码，但糟糕的数据模型）。其原因在于出色的数据设计，然后代码和应用程序实际上是自己编写的。借助出色的数据模型，您可以轻松地根据不断变化的业务规则进行更改，这再次有利于出色的数据设计而不是出色的代码设计。当您拥有良好的数据模型时，您还可以重新考虑代码超时。因此，借助良好的数据模型，您可以将表单和功能以及 UI 迁移到 .net 中，并且当现有数据模型有意义时，您可以无缝且轻松地做到这一点。

此外，转向这些新技术是没有意义的，而且您将更少介绍为现有业务流程引入诸如自助式 Web 门户之类的东西的可能性。因此，今天我们现在可以允许客户操纵和使用当前锁定在系统中的一些信息。这可能很简单，因为他们检查订单状态而不是浪费宝贵的客户电话时间。或者可能是一些简单的事情，例如加拿大的一家大型包裹公司在实施包裹跟踪系统的第一年就节省了大约 10,000,000 美元。或者可能是让客户查看他们的帐户余额这样简单的事情。

因此，目前在市场上，这些自助式客户门户网站系统允许客户输入、使用和获取他们的信息，而不是调用组织内的一些雇员，然后他们转身启动应用程序，然后操纵该客户在电话中的信息。还不如让客户做这个工作！因此，从订单状态、欠款余额、银行业务等等，今天真正的樱桃模型票是允许客户在代表内部应用程序正在创建的所有有价值信息的单元服务门户网站上使用。

如前所述，您必须问，人力和人员将在哪里来构建和维护此应用程序？显然，必须以某种方式创建包含大量表格和表格的现有系统，并且需要花费大量的时间和精力。您必须要问的关键概念是，那些用于构建现有应用程序的重大投资和资源来自哪里？那么谁来维护新系统呢？换句话说，您需要设计新系统以降低维护成本。（我的软件的新版本每年可以为客户减少多达 10 或 15 小时的维护时间）。

说到底，好的软件开发和好的设计就是好的设计。如果系统现在满足您的业务需求，使用 Access、VB6 或 vb.net 并不重要。

还要指出的是，新版access 2010，可以创建.web表单。它们是 XAML（zammel .net 表单）。我要指出这一点，因为将前端皮肤从访问 .net 更改为您几乎没有收益，除非基础数据结构和设计也被修改以利用可以通过新技术完成的新的可能业务流程（例如那些小区服务门户网站）。在我看来，简单地重新绘制以 .net 形式结尾的字体真的非常浪费金钱，除非正在解决其他问题，例如数据模型，或者某种类型的门户网站可以提高这里的灵活性。

您已经在这里提出了一些很好的建议。请记住，这实际上归结为这些人希望在 .net 中重写该软件的目标和原因。那些新的目标和愿望最好不要以简单地将您现在拥有的表格重新制作成 .net 为借口，因为这将真的一事无成，并且不会提高他们解决当前系统不断变化的业务需求的能力using 显然过去一直在做。

祝你好运我不认为这是可以在简单的论坛帖子中回答的问题，但至少你在这里有很多东西要咀嚼，这样你就可以开始了。

【讨论】：

@David：实际上，我是一名软件开发人员，而 MS Access 是一个 RAD 工具，主要旨在允许非开发人员创建对他们有用的东西。使它擅长的事情也使它在我看重的事情上变得糟糕。对于经验丰富的开发人员来说，MS Access 总是是错误的工具。如果这让我成为你眼中的“狂热者”，那就这样吧。人生苦短，无法取悦所有人，诚实是宝贵的。
@Albert：我也看到 Excel 被用作穷人的数据库。并不意味着我们应该是穷人。
@Steven Sudit：你基本上是在说我不是开发人员，因为我在 Access 中开发。这真的是偏执。当然，Access 允许非开发人员完成很多工作，但在经验丰富的开发人员手中，它可以做很多很多。如果你没有意识到这一点，那很可能是因为无知。如果不是，那就是不合理的偏执。无论哪种方式，它都不是基于现实的。
@Steven Sudit：Albert 没有建议使用 Excel 来代替 Access ——他只是建议如果您将 Access 从用户手中拿走，他们将退回到 Excel 之类的东西。你有任何阅读理解水平吗？还是你一口气吸收的太多了？
Access 不是开发者工具只是一种观点。如果 access 不是开发人员工具，那么为什么 Access 2010 将源代码控制嵌入到产品中？您认为 VSS 源代码控制支持等功能适用于非编码人员和最终用户吗？ Access 是一种工具，涵盖了从非编码人员到断开连接记录集的技能，以及在 SharePoint 上创建浏览器中性网站、强大的功能区开发支持，甚至对 SQL Auzre（云 sql）的支持都内置在产品中。当您谈论 Web 表单、VSS 甚至 Azure 支持时，几乎不是非开发人员工具。