将大型MS Access应用程序移向.Net的最佳做法？

我们有一个非常庞大的MS Access应用程序，最初是为满足我们的个人需求而开发的，后来变成了商业软件并成功销售。该软件是一种“为您的企业而设计的全方位软件”，包含文档管理系统，企业资源计划，库存管理，客户关系管理，数据分析等多个模块。我们对当前的情况非常满意应用程序的功能，但是为了满足客户的要求，我们意识到我们必须转向新的事物。

我们决定逐渐将应用程序移至.Net，因为我们可以坚持使用Visual Basic .Net：尽管它是此处大多数开发人员的新语言，但我们对VBA以及在VB6中实现的数十个小型项目都有很深的了解。

我们已经开始将应用程序的数据层功能移至MS SQL Server，以便每个数据操作和搜索都直接在服务器上执行。

我们正在寻找的是逐步移动我们广泛的GUI的最佳实践（大约500-600种不同形式，包括子表单，大约200种具有多语言支持的报告等）。潜在客户最近要求在DMS中对文档实施异步数据加密之后，我们也很乐意将这部分与MS Access完全脱钩，并在.Net中进行实现。

问题是如何将.Net应用程序与现有的MS Access系统无缝集成，以便我们可以使用某些参数（用户权限等）调用它，并启用此应用程序与正在运行的MS Access应用程序之间的数据交换。

编辑：

我们试图应用Martin Fowler的“ 企业集成模式 ” 一书中的一些实践，以实现MS Access应用程序与我们为各种需求在.Net中实现的一些小型实用程序之间的集成。但是我们仅设法使用“共享数据库”模式，对我们的解决方案并不满意。

例如，我们实现了一个作为Windows服务运行的小型实用程序，该实用程序使用POP3连接自动从邮件服务器下载所有邮件并将它们存储到一个表中，而所有附件都存储在文件系统中。

我们主要要做的是使用ADO.NET直接访问MDB格式的MS Access数据库，并用一些处理过的数据填充表格（例如上例中有关邮件消息的数据：我们有FROM，TO，CC，BCC，主题和身体）。

使用.Net的MDB数据格式绝对没有问题，此外，我们不想再使用MDB并将几乎所有内容升级到MS SQL Server 2008了-这给了我们更多关于数据管理和可伸缩性的自由。

这里的主要问题是我们不知道如何在Access中实现某种“回调”，以便我们可以在数据更新时触发某些VBA代码的执行。

MS Access 2010支持对数据表的更新和插入触发器，我们寄予了厚望，但事实证明，我们只能对这些触发器使用MS Access宏，并且无法在触发器内执行任何自定义VBA代码。

我们还尝试了一些解决方案，将击键直接发送到MS Access窗口，以模仿某些用户调用的数据重新查询。这可行，但是我们认为这不是可以在生产中使用的可行解决方案。

我们还研究了用于MS Access的DDE，但找不到实现DDE命令并将其用于内存数据和命令交换的良好示例解决方案。

因此，主要问题是使MS Access和.Net应用程序共存并相互交互。

编辑2：

我忘了提一下我们在VBA中也实现了MSMQ库，以便在.Net和MS Access之间传递消息，问题再次出在这里，缺少回调：我们真的不得不在队列中轮询新消息，并且鉴于VBA并不真正支持多线程，这并不是一个很好的解决方案。

这将是一个大型且非常复杂的项目。我曾多次负责将Access数据库迁移到.NET，但从未如此规模。我同意渐进的方法可能是最现实的。尝试一次完成所有任务是一种简单的失败方法。

与其他答案一样，第一步也是最重要的一步是将所有内容移至SQL Server。在执行此操作时，请记录数据库（如果尚未完成），并确定要重构的区域（如果存在）。满足不断发展的需求而增长的Access数据库通常具有可以从全局上进行改进的数据模型。

接下来，识别“自包含”的应用程序模块。因为这是一个万事俱备的数据库，所以其中的模块可能几乎彼此完全脱节。在这些不连贯的部分之后，请确定一个较小的模块，该模块可以从更新中获得最大收益，并首先进行更新。

迁移到.NET时，不要只是对应用程序进行简单的一对一复制。收集用户的输入以识别当前应用程序的痛点。您希望您的第一个迁移部门取得巨大成功，从而获得其他所有人的全面支持。

完成第一个单元后，请查看在挑战，困难等方面发生的情况，并继续进行下去。

我强烈不鼓励的一件事是实施部分工作的模块（例如：“我们迁移了CRM，但是功能X，Y，Z尚未在新系统中”）。当用户的旧系统“非常好”时，这将使用户很快因不完整的系统而感到沮丧。这种开发可能在其他域上也可以正常工作，但是在用户看不到旧的Access独石“完全没错”并且不了解迁移需求的企业中就无法使用。

这是一种通过突变将您的MS Access应用程序转换为VB.Net应用程序的计划。

这不是一个总体计划，以下计划取决于您描述的项目。

步骤1：将所有数据迁移到SQL Server

不要使用ODBC进行对SQL Server的连接访问，而应使用Access Project（ADP）。Access项目是一个扩展名为.adp的Access文件，它具有完整的Access功能（宏，表单，报表，模块），但连接直接在SQL Server数据库上，而不是MDB文件。ADP文件与MDB文件非常兼容。它们似乎在Access 2010中不受支持，尽管实际上该功能是隐藏的，但它得到了很好的支持。像MDE一样，ADP文件可以“编译”为ADE文件。

迁移到SQL Server几乎不需要对数据结构和代码进行任何修改，但是所有这些都非常容易迁移。毕竟这是最终目标。

不用再为VBA或VB.Net代码触发数据库事件了。从技术上讲，这可以使用SQL Server扩展存储过程来完成，但这是一个非常糟糕的技巧。您的项目有未来的生命，因此最好避免这种分解桥梁来实施其数据结构。通常，与数据库触发器一起使用，虽然很聪明，但是很难维护。

步骤2：使身份验证统一

您的应用程序不基于访问安全性（MDW文件）是一件好事。

为VB.Net应用程序的目标身份验证制定计划，然后定义一种将Access身份验证迁移到此目标的方法，以便在两个应用程序之间具有统一的身份验证。

由于身份验证在应用程序体系结构中是横向的，因此在Access版本与VB.Net版本之间进行分割更容易。

步骤3：准备令牌功能，以便在Access和VB.Net之间建立桥梁

您说过，Access UI必须打开带有一些准确参数和身份验证的VB.Net UI。您可能必须以另一种方式做同样的事情。

一个好的解决方案是基于令牌表构建一个小的令牌功能：列可以是令牌ID（整数），令牌键（长字符串），令牌日期和参数列表（长字符串或文本）。每次Access需要打开VB.Net屏幕，然后使用参数将令牌保存在数据库中，然后仅使用令牌ID和令牌密钥打开VB.Net应用程序。VB.Net打开，在数据库中搜索令牌ID，检查密钥（这适用于身份验证）并读取参数。然后打开相应的表格，然后执行所需的操作。不要忘记给令牌一个持续时间，并清理旧令牌。

如果您需要从VB.Net回调到Access（可能会），那么我认为可以使用OLE在打开的MDB Access文件上激活一些VBA代码。

步骤4：逐屏幕，逐模块迁移UI和模块

现在，大部分准备工作已经完成。您可以开始将用户界面从Ms Access迁移到VB.Net。

没有好的自动工具可以执行此操作。VBA和.Net太不同了。您必须为这种迁移做准备。从一个小表格开始，例如“关于”框，然后从简单表格过渡到复杂表格。当然，您将不得不捆绑并安排一些迁移，但是您将逐步将屏幕，报告和库从Ms Access迁移到VB.Net。

我很惊讶您使用Access所做的所有事情。您不问.NET Windows窗体或.NET WPF有一个非常重要的问题。WPF的学习曲线更陡峭，但我认为它具有更好的UI会更强大。最近，我们将商业应用程序从Forms转换为WPF，我们已经获得了更多的销售。我们还添加了新功能，但WPF UI更加性感。查看您的桌子设计并清理-现在是时候了。确保声明所有FK。在Access中，您有时可以轻松地动态添加内容。如果这是您的第一个WPF UI，请构建一些原型。我们可以在WPF中添加更多内容，以使新应用程序具有更多功能，更少的屏幕以及更少的代码。您将从讨厌XAML变成多么热爱它。考虑像MVVM这样的结构。

因为您已经对Access对象模型有了很好的了解，所以我认为您想从.NET应用程序中使用Access Interop。它应该（或多或少）使您能够自动控制Access应用程序，而无需DDE的不透明性。

我不了解您的业务逻辑层，但是您也可以在.NET应用程序中访问MS Access数据库。如果不仅仅是获取数据，还可以在程序（VB6和VB.NET应用程序）之间实现TCP / IP连接。请查看有关CodeProject的文章。

您正在寻求有关如何做错事的最佳实践。没有一个。最佳实践包括如何有效创建可维护的系统，以便即使公交车出故障了，并且整个团队都需要精打细算，开发和支持都可以继续。您描述的系统将派遣大多数开发人员到山上奔跑。您拥有使用过时技术构建的产品，并希望与当今的技术对接。而且您想要这样做，而无需解决您为核心产品描述的任何反模式。那些愿意解决此问题的开发人员可能不愿意按照您提出的条件这样做。

但是，您的总线尚未崩溃，因此您可以利用了解系统的现有团队。我发现逐步发展的最佳方法是使用敏捷方法论。它支持一种迭代过程，该过程可以尽早解决高风险需求并很好地满足业务需求。

我们决定逐渐将我们的应用程序移向.Net

通常是一个错误。最佳做法是不要“逐步”尝试。

尽管对于大多数开发人员来说，这是一种新语言，但我们对VBA以及在VB6中实现的数十个小型项目都有很深的了解。

决定的依据不是很好。如果您想学习一种新语言，请不要学习VB。学习C＃或Java之类的更好的东西。

“对于这里的大多数开发人员来说，这是一种新语言，我们对VBA有很深的了解”是“我们有不想激怒的VBA Guru”的通用代码短语。那也可能是坏的。

我们正在寻找的是逐步移动广泛的GUI的最佳实践

最佳做法不涉及“渐进式”。它们涉及“完全丢弃”。

我见过的渐进式迁移已经分解，因为它是如此困难。

您最好这样做。

1. 保留最有价值的资产。数据。将所有数据移动到SQL Server。所有的。重写所有MS-Access，以使用到SQL Server的ODBC连接。马上。

2. 解雇在MS-Access中创建临时表或数据或任何内容的任何人。所有数据都必须存在于MS-Access之外的数据库中。MS-Access中的数据是造成问题的原因，所以请立即停止并确保每个人都同意。如果他们不同意，则在尝试摆脱MS-Access的同时，请他们找一份新工作，不涉及对MS-Access进行黑客攻击。

3. 查找一个报告框架，该框架将自动生成接近您现有报告的报告。没有编程。只要给它一张桌子或一个视图，然后砰！完成。

4. 列举所有500个报告。将它们划分为可以使用该工具轻松构建的报告和更难的报告。将难处理的优先级划分为“必须具有”，“应该具有”，“可以具有”和“以后不会使用”，替换自动报告，并且该报告工具必须完全在MS-Access之外进行报告。

   我的经验是，数据库视图经常在大约20个左右的报告中被重用。据此，我想您有25个相关的观点，可从中得出500份报告。任何可以自动生成报告的工具都应从少量精心设计的SQL视图中处理大多数报告。对于自动化工具而言，一些报告将过于复杂或困难。

5. 查找一个可自动构建CRUD事务的开发框架。

6. 将您的200个表单分为CRUD表单（可以自动生成）和非CRUD表单。在非CRUD中，使用MoSCoW（必须，应该，可能，不会）规则确定优先级。

   通常，60-80％的申请表都是简单的自动化CRUD表单。20-40％更复杂，需要更多熟练的编程。基于此，您有120到160个CRUD表单，您无需重写即可自动执行。您有40-80个严重复杂的交易。

7. 建立CRUD表格和必备的非CRUD表格。

8. 评估差距。重新确定优先级并开始处理“应该拥有”列表中最重要的部分。

完全放弃Access可能是最容易的。避免渐进主义。

您最终将花光所有的钱。

您不妨为此预算并立即支出。

由于尝试管理共存的复杂性，尝试逐步执行此操作实际上可能会更昂贵。