从ms访问客户端接口切换到可执行文件

时间:2008-12-23 11:33:39

标签: .net vb.net ms-access

在VB,.NET或其他微软技术中是否存在类似于ms-access表单的对象?

我们现在使用Access来开发客户端界面,并在过去的两年中取得了一些成功。我们正在使用一系列开发工具充分利用元模型(我们有表格,本地查询,菜单,控件,连接等),并坚持使用一些强大的编程技术,例如,所有可视化基本代码都是位于模块或类模块中。

因此,表单中保存的VB代码已经标准化,并且其生产完全自动化,根据其类型向控件添加预定义事件(这已经被简要暴露here)。

除了这些表单之外,我们使用的所有其他对象都可以采用Access / mdb文件的方式:本地表可以保存为xml文件,模块可以作为可视化基本文件导出/重写用另一种语言。我们不使用任何宏(除了'autoexec'之外),报告(我们使用Crystal Reports加载项)或查询(存储在'查询'表中)

在另一种技术中查找类似的“表单”对象将使我们能够分发独立/ .exe运行时文件,而不是我们当前的.mdb文件和ms-access运行时的组合。

3 个答案:

答案 0 :(得分:1)

我认为我误解了这个问题,但在我看来,你似乎在询问WinForms和/或WPF。基本的.NET Windows客户端表单。

这将是一个开始的地方。

http://windowsclient.net/getstarted/

至于哪一个使用,我自己并不清楚。所以我问了

When is Windows Forms the correct choice vs WPF?

答案 1 :(得分:1)

在我看来,主要的答案必须是常规的Windows表单,或者如果您更喜欢(并且是最新的)WPF。两者都对数据绑定等有很好的支持,但是,它们都不能直接与ms-access表单相比。并且这些表单不能单独存储,而只能作为程序集的一部分存在。好吧,WPF可以像位,但即使这样,也几乎总是有很多代码隐藏(这是程序集的一部分,不可分离)。

答案 2 :(得分:1)

您将发现无论您做什么,都需要重新编码这些表单,因为没有其他应用程序具有与MS Access相同的体系结构。 VB.NET中的WinForms实际上并不相同,并且为有经验的MS Access开发人员提供了几个问题。

你可能真的发现最好的想法就是选择像WPF这样的东西,因为它是如此不同以至于它可以帮助你的开发人员专注于他们需要做的事情,而不是试图移植逻辑。

目前还不清楚这些形式中的业务逻辑究竟是什么。它们应该是简单的前端验证代码,最糟糕的是一些数据绑定和事件处理。你还需要能够根据表自动化表单吗?在这种情况下,某种形式的代码生成器会有所帮助(尽管这不是一个很好的GUI设计策略)。