我正在使用ms-access开发用于数据库管理的前端解决方案.我必须承认ms-access VBA是大规模应用程序开发的一个固定限制,这就是为什么我一直在转变使用c#而不是VBA的想法.
实际上,除了一个东西:表单之外,很容易摆脱ms-access中的所有内容.在数据显示和编辑方面,这些特别快速有效.在最新版本的ms-access中,表单就像类一样,因此您可以在运行时专门管理同一表单的一个或多个实例.在连续模式下使用时,它们可用于操作数据"excel方式",具有行和列显示,过滤和排序的可能性.简而言之,我喜欢它.
当然可以在c#(或其他类似语言)下对这个表单对象进行反向工程,但这可能已经完成了:你曾经使用过库,activeX控件或任何其他类型的附加组件吗？在c#中操作类似msacces的形式的可能性？
编辑:根据Renaud的评论,我承认没有兴趣仅转换表单的布局部分,并且无法转换其自定义/ VBA部分.在我们的特定情况下,我们很久以前就停止在表单中使用自定义VBA代码,并且从模块管理表单属性,方法和事件.这甚至在这里讨论过.
实际上,我们所有的表单都依赖于一个通用模板,并且是自动构建的"表单"和"控件"表.所有基础事件管理代码生成都是自动化的:根据其类型,控件与选定事件相关联,事件代码提供应用程序模块中保存的标准\通用程序.这使我认为可以将我们的'ms-access表单技术'转移到.NET平台.
我不知道任何项目可以让你使用Access应用程序并在.Net或其他任何东西重建它.我相信有一些很好的理由说明为什么这些工具只能在他们提供的东西上非常有限.
一个只能转换表单布局的工具将非常缺乏目的:在.Net中手动(重新)创建功能布局非常容易,无论是WinForms还是WPF.
每个屏幕可能需要几个小时,但速度足够快.
一个自动化工具很难将Access表单翻译成.Net中的好看:
很多Access应用程序在UI方面设计不佳,控制位置选择不当,依赖自定义颜色方案和技巧来弯曲有限的访问控制到一个人的意志.
最重要的是,你有很多非常特定于Access的对象属性,并且在不需要大量额外支持代码的情况下也不能很好地转换为.Net.
但我认为会议室中的大象是VBA:最复杂的Access表单是通过VBA控制UI和业务逻辑来定制的,如果没有一些重大的努力就无法将其转换为.Net.
事实上,MS Access应用程序是围绕一个过程的,以模块为中心的方法而不是面向对象的方式构建的,并且Access应用程序总是具有非常差的UI和业务逻辑分离,这无助于原因.
直接翻译 - 如果可能的话 - 只会创建一个糟糕的.Net应用程序.
有许多框架可用于构建与Access类似的简单/复杂业务应用程序.
Developer Express拥有eXpressApp Framework,允许您构建和自定义UI,生成数据库,管理用户,安全性等,并且可以轻松地构建几乎没有代码的数据视图(您可以根据需要添加尽可能多的代码,这都是.Net).用户界面使用了出色的控件,这些控件在行为方面远优于Access,并且可以自定义.
该框架同时针对桌面和Web(您创建一个项目,然后自动获得).唉,你必须拥有一个在这个日期成本2200美元的通用订阅并不是很便宜(每年续订800美元).
根据您的MSDN订阅,另一种免费或便宜的产品是LightSwitch.
LightSwitch被一些人视为现代的,以开发人员为中心的Access继承者.它最初以Silverlight为目标,可在企业中轻松部署,但最新版本也针对HTML5,因此您可以"在任何地方运行您的应用",甚至是平板电脑.
这里的原则是轻松构建适当的面向数据的表单和视图,以允许快速数据输入和自定义报告.
和你一样,我经常考虑如何将现有的MS Access应用程序转换成.Net,但是我对细节的思考越多,它就越发,然后你看看人们用Access做了些什么,你就知道了任何工具要成功,它必须处理办公室用户构建应用程序的所有可怕方式,而这只是疯了.
构建Access应用程序的方法太多了,其中大多数都非常差,没有机会在不改变范式的情况下轻松转换,通常会强制完全重写.
| 归档时间： |
|
| 查看次数： |
1594 次 |
| 最近记录： |