从MS Access应用程序迁移到.Net应用程序的优点

use*_*429 8 .net c# ms-access

在MS-Access中开发了一个现有的中型应用程序,目前仅有15个用户使用.我们现在正在解决是否要刮开现有的MS-Access应用程序并在.Net(可能是Windows或Web)应用程序中开发相同的功能.由于这不是一个巨大的应用程序,我们在将功能转移到.Net应用程序方面是否有任何积极意义?两者之间的比较(.Net Vs MS-Access) - 在性能,安全性等方面,也可以理解在.Net中开发应用程序的优势也会对我有所帮助.

Doc*_*own 13

恕我直言,一般比较".NET"与"MS-Access"没有意义.当然,您可以将当前应用程序与迁移的应用程序的预期功能/性能/安全性等进行比较,但是您必须了解有关应用程序详细信息以及您将如何设计".NET"端口的更多信息.

如果您正在寻找证明移民工作合理性的理由,您应该问自己以下问题:

  • 是否有人在您当前的应用程序中缺少使用Access前端无法轻松开发的功能?这将是改为.NET的一个很好的理由.
  • 谁在将来进行维护?对VBA只有一点经验的AC#程序员,或者对C#没有或只有一点点了解的经验丰富的Access程序员?或者你可以完全自由选择你喜欢的任何类型的维护开发人员,所以这没有什么区别?
  • 你是否坚持使用Access应用程序的特定MS-Office版本?或者可以轻松迁移到更新的版本?要将自己与特定的Office平台分离,可能是更改开发平台的一个很好的理由.
  • 你的后端怎么样?您是否满意(即使您的前端进入.NET,您也可以将Access保留为后端),或者您是否需要真正的客户端 - 服务器数据库(在大多数情况下,您可以将Access应用程序保留为前端比完整的.NET迁移更省力?像MS-SQL服务器这样的CS数据库允许您使用更多的同时用户,并且具有改进的安全模型(当然是为了管理开销的成本),但实际上并没有为什么不能将Access作为前端保留的说法.
  • 你们有多少人访问的"RAD"的特点在当前的应用中使用(例如,可能有一个访问的形式自动切换到一个表像模式,或报告功能).对于其中一些功能,.NET框架中没有现成的解决方案,您必须以不同的方式解决或使用第三方工具.另一方面,这是继续使用Access的一个很好的理由.

编辑:这是Joel Spolsky的一篇超过10年的文章

http://www.joelonsoftware.com/articles/fog0000000069.html

这似乎与这个话题有些相关.阅读他对丢弃现有应用程序的想法,从头开始.