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

Question

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

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

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

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

我们不能留下一半的 VB/C# 应用程序和一半的 Access 应用程序，它必须“看起来”都是一个应用程序，即使迁移到一半。

提前致谢。

编辑:关于我们所做的工作以及我们为何考虑放弃 Access 的更多信息。

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

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

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

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

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

Answer 1

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

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

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

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

Things You Should Never Do, Part I

by Joel Spolsky

They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

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

乔尔继续指出，在过去的 10 年里，那篇文章仍然是他最受欢迎的文章之一(并且有些争议)

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

我还要指出，我在这个行业工作了很长时间(包括已出版的和 Access 书籍的技术编辑)，我还做过从大型机系统到桌面的迁移项目。而且，我还完成了桌面数据库系统到大型主机系统的迁移。

我只能说，很少看到一个应用程序有这么多表。事实上，这个问题立即敲响了警钟。

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

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

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

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

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

我只是指出，我的蜘蛛感应向我表明这里的数据模型将是一个真正的挑战。请记住，我总是会把糟糕的代码和设计好的数据模型反过来(伟大的代码，但糟糕的数据模型)。这样做的原因是出色的数据设计，然后代码和应用程​​序实际上是自己编写的。有了出色的数据模型，您可以轻松更改以适应不断变化的业务规则，这再次有利于出色的数据设计，而不是出色的代码。当您拥有良好的数据模型时，您还可以重新考虑代码超时。因此，借助良好的数据模型，您可以将表单和功能以及 UI 转移到 .net 中，并且当现有数据模型对保留有意义时，您可以无缝且轻松地完成此操作。

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

所以现在在市场上，这些自助式客户门户网站系统允许客户输入、使用和获取他们的信息，而不是调用组织内的一些雇员，然后他们转身启动应用程序，然后为此操纵信息客户在打电话时。不妨让客户来做这项工作!因此，从订单状态到欠款余额、银行业务或其他任何东西，今天真正的樱桃模型票是允许客户在代表该内部应用程序正在创建的所有有值(value)信息的单元服务 Web 门户上使用。

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

归根结底，好的软件开发和好的设计就是好的设计。如果系统现在满足您的业务需求，使用 Access、VB6 或 vb.net 都没有关系。

我还应该指出，新版本的 access 2010，可以创建 .web 表单。它们是 XAML(zammel .net 形式)。我指出这一点，因为将前端皮肤从 Access 权限更改为 .net 的 yield 非常小，除非也修改底层数据结构和设计以利用可以通过新技术完成的新的可能业务流程(例如那些单元服务门户网站)。简单地用 .net 形式重新绘制字体结尾在我的拙见中实际上非常浪费金钱，除非正在解决其他问题，例如数据模型或某种类型的门户网站，这些问题将在这里提高灵活性。

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

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