Fri*_*ich 5 java ms-access code-migration converters
我读过几篇提到从一种语言到另一种语言的转换器的文章.
我对使用这种工具持怀疑态度.有没有人知道或有经验让我们说Visual Basic到Java或vs转换器？只是一个例子来挑选
http://www.tvobjects.com/products/products.html,声称在这方面是"世界领导者"左右,但如果读到这个:
http://dev.mysql.com/tech-resources/articles/active-grid.html
在那里,作者说:
"The consensus of MySQL users is that automated conversion tools for MS Access do not work. For example, tools that translate existing Access applications to Java often result in 80% complete solutions where finishing the last 20% of the work takes longer than starting from scratch."
Well we know we need 80% of the time to implement the first 80% functionality and another 80% of the time for the other 20 %....
So has anyone tried such tools and found them to be worthwhile?
试过吗？不,实际上构建(不止一个)语言转换器.
这是我(和我的同事)为B2 Spirit Stealth轰炸机建造的一个将使用传统语言JOVIAL编码的任务软件转换为可维护的C代码,并实现100%自动转换.其中一个要求是我们不允许看到实际的源代码.可不是闹着玩的.
你是对的:如果你只获得中等转换率(例如70-80%),那么完成转换的努力仍然非常重要,如果你真的可以做到的话.我们的目标是95%+并且在被告知要更加努力时做得更好,就像B2的情况一样.人们接受中等高速率转换器的唯一原因是因为他们无法找到(或者不会资助!)一个更好的转换器,坚持从现在开始,并接受这样转换它的事实可能是痛苦的(通常他们不会知道多少)但实际上比从头重建它更痛苦.(我碰巧同意这种评估:一般来说,尝试从头开始重新编码大型系统的项目通常会失败,使用中高转换率工具的转换不会有很高的失败率.)
有很多糟糕的转换工具,有一些PERL代码在文本字符串上运行regex,或者一些基于YACC的解析器,代码生成基本上是编译单元中每个语句的一对一.前者是由那些从天而降的人转而建造的.后者通常由善意的工程师构建,这些工程师没有合适的编译器背景.
对于一个非常糟糕的例子,请参阅我对这个关于COBOL迁移的问题的回答:将遗留Cobol/PL1迁移到Java的经验,这正是一个直接的语句翻译器...产生引起术语"JOBOL"的东西.
要获得如此高精度的转换率,您需要高质量的解析器,并且需要构建保留语义的高质量转换规则,并针对目标语言属性和特殊情况进行优化.从本质上讲,您需要的是可配置的编译器技术.我们成功的原因,恕我直言,是我们的DMS软件再造工具包,旨在完成这项工作.(我是建筑师;看看我的SO图标/生物).
许多仔细的测试也有帮助.
DMS"知道"编译器对代码的了解,因为它具有感兴趣的语言的类似编译器的前端,并且具有构建AST,符号表,控制和数据流,调用图的能力.它使用了编译器社区在过去半个世纪发明的大部分编译器技术,因为这些东西已经被证明在翻译中很有用!
DMS知道更多的比大多数编译器知道,因为它可以读取/分析/一下子改变了整个应用程序; 大多数编译器都坚持使用单个编译单元.因此,可以编码依赖于整个应用程序而不仅仅是当前语句的转换规则.我们经常添加特定于问题或应用程序的知识来改进翻译.这通常在转换语言的特殊功能或调用库时出现,其中必须将库调用识别为特殊习语,并将它们转换为对目标库和语言构造的组合的调用.
此功能用于构建转换器(例如,JOVIAL转换器)或特定于域的代码生成器.
更常见的是,我们构建复杂的自动化软件工程工具来解决客户特有的问题,例如程序分析工具(死代码,重复代码,样式破坏代码,指标,架构提取......)和批量更改工具(平台[不是langauge]迁移,数据层插入,API替换,...)
在我看来,MS-ACCESS问题几乎总是有这样的问题,标签吸引更广泛的StackOverflow人群,回答的人在这里错过了关键问题,我读到:
是否有任何工具可以成功将Access应用程序转换为任何其他平台？
答案是
绝对不
原因很简单,同一家族中使用类似UI对象模型的工具(例如VB6)缺少Access默认提供的东西(如何将Access连续子窗体转换为VB6而不丢失功能？ ).而其他平台甚至没有与VB6和Access共享相同的核心模型,因此有更多的障碍要清除.
引用的MySQL文章非常有趣,但它确实混淆了无法开发的应用程序带来的问题与使用的开发工具带来的问题.糟糕的数据模式不是Access固有的 - 它是[大多数]新手数据库用户所固有的.但文章似乎将此问题归因于Access.
并且完全忽略了修复模式的可能性,将其升级到MySQL并将前端保持在Access中,这是迄今为止解决问题的最简单方法.
这正是我对那些没有获得Access的人的期望 - 他们甚至不认为Access作为安全的大容量服务器数据库引擎的前端可以成为解决问题的最佳解决方案.
那篇文章甚至没有真正考虑转换Access应用程序,这是有充分理由的.我见过的所有声称要转换Access应用程序(到任何平台)的工具要么只转换数据(在这种情况下它们根本不转换应用程序 - 笨蛋!),或者盲目转换前端结构,Access应用程序中的UI对象与目标应用程序之间的1:1对应关系.
这不起作用.
Access的应用程序设计特定于自身,而其他平台不支持同一组功能.因此,必须将Access功能转换为转换后的应用程序中原始功能的工作替代品.在我看来,这不是以自动化方式完成的事情.
其次,在考虑转换Access应用程序以在Web浏览器中进行部署时,整个应用程序模型是不同的,即从有状态到无状态,因此不仅仅是少数Access功能不受支持,而是完全不同的问题UI对象如何与数据交互的基本模型.也许100%未绑定的Access应用程序可以相对容易地转换为基于浏览器的实现,但其中有多少？这意味着Access应用程序不使用任何子表单(因为它们不能解除绑定),以及仅使用来自富事件模型的少数事件的应用程序(大多数仅使用绑定表单/控件).简而言之,100%未绑定的Access应用程序将是一个与整个Access开发范例作斗争的应用程序.任何认为他们想在Access中构建未绑定应用程序的人真的不应该首先使用Access,因为Access的整个点是绑定的表单/控件!如果你消除了这一点,那么你已经抛弃了大部分Access的RAD优势而不是其他开发平台,并且几乎没有任何回报(除了巨大的代码复杂性).
要在Web浏览器中构建用于部署的应用程序,以完成与Access应用程序相同的任务,需要从头开始重新设计应用程序UI和工作流程.没有转换或转换可行,因为成功的Access应用程序模型与成功的Web应用程序模型是对立的.
当然,所有这些都随Access 2010和带有Access Services的Sharepoint Server 2010而变化.在这种情况下,您可以在Access中构建应用程序(使用Web对象)并在Sharepoint上部署,以便用户在浏览器中运行它.结果在功能上100%等效(和90%可视),并在所有浏览器上运行(此处没有特定于IE的依赖项).
因此,从今年6月开始,转换Access应用程序以便在浏览器中部署的最便宜方式可能是升级到A2010,将设计转换为使用所有Web对象,然后使用Sharepoint进行部署.这不是一个简单的项目,因为与客户端对象相比,Access Web对象具有一组有限的功能(例如,没有VBA,所以你必须学习新的宏,它比旧的宏更强大,更安全,因此,对于那些熟悉Access遗留宏的人来说,这并不是一件可怕的困难,但对于在网络上部署的全面重新设计,它可能要少得多.
另一件事是它不需要对最终用户进行任何再培训(因为网络对象版本与原始客户端版本相同),因为它在Access客户端中与在Web浏览器中相同.
所以,简而言之,我认为转换是一种幻想,几乎总是不值得努力.事实上,我同意所引用的观点(即使我对该来源的其他评论有很多问题).但我也提醒说,转换的愿望往往是错误的,并且错过了更便宜,更简单,更好的解决方案,不需要从上到下批量更换Access应用程序.通常,Jet/ACE对数据存储的不满使人们误以为他们必须更换Access应用程序.确实,许多用户开发的Access应用程序充满了可怕的,不可维护的妥协,并与口香糖和挽救丝结合在一起.
这并不意味着它很容易 - 通常不是这样.正如我一直告诉客户的那样,建造新房子通常比改造旧房子更容易.但我们改造旧房屋的原因之一是因为它们具有我们不想失去的不可替代的特征.通常情况下,Access应用程序隐含地包含许多业务规则和工作流建模,这些规则不应该在新应用程序中丢失(旧的Netscape难题,步伐Joel Spolsky).对于尝试移植到不同平台的外部开发人员来说,这些事情可能并不明显,但对于最终用户而言,如果应用程序产生的结果与旧应用程序相比只差一分钱,那么他们将会感到不快(并且可能应该,
无论如何,我已经漫步了很长时间,但我认为转换永远不会有效,除了最琐碎的应用程序(或者那些被设计为转换的应用程序,例如,100%未绑定的Access应用程序).我将全部修改以取代替换.
但是,当然,这就是我的生活方式,即修复Access应用程序.