.net 从ms access客户端接口切换到可执行文件

在VB、.NET或其他microsoft技术中是否有类似ms access窗体的对象？

在过去的两年中，我们一直在使用Access开发客户端接口，取得了一些成功。我们正在使用一系列开发工具，充分利用元模型（我们有表格用于表单、本地查询、菜单、控件、连接等），并坚持一些强大的编程技术，例如，所有visual basic代码都位于模块或类模块中

因此，表单中保存的VB代码已成为标准，其生成是完全自动化的，根据控件的类型向控件添加预定义事件（这一点已简要公开）

除了这些表单之外，我们使用的所有其他对象都可以以某种方式从Access/mdb文件中删除：本地表可以保存为xml文件，模块可以导出为visual basic文件/用其他语言重写。我们不使用任何宏（除了“autoexec”宏）、报告（我们使用Crystal reports插件）或查询（存储在“queries”表中）

---

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

我想我误解了这个问题，但在我看来，您是在问WinForms和/或WPF。基本的.NET Windows客户端窗体

这将是开始的地方

至于用哪一个，我自己也不太清楚。所以我问

---

在我看来，主要的答案必须是常规的windows窗体，或者如果您喜欢（并且是最新的）WPF。两者都对数据绑定等有很好的支持，但都不能直接与ms access表单相比。这些表单不能单独存储，而只能作为程序集的一部分真正存在。嗯，WPF可以像xaml一样独立存在，但即使如此，后面也几乎总是有大量代码（这是程序集的一部分，不可分离）。

您会发现，无论您做什么，都需要重新编写这些表单，因为没有其他应用程序具有与MS Access相同的体系结构。VB.NET中的WinForms实际上并不相同，对于有经验的MS Access开发人员来说，它有几个要诀

实际上，您可能会发现，最好的方法是使用WPF之类的东西，因为它非常不同，可以帮助您的开发人员专注于他们需要做的事情，而不是尝试移植逻辑

---

目前尚不清楚这些表单中会包含哪些业务逻辑。它们应该是简单的前端验证代码，最糟糕的情况是带有一些数据绑定和事件处理。您仍然需要能够基于表自动化表单吗？在这种情况下，某种形式的代码生成器会有所帮助（尽管这不是一种很好的GUI设计策略）。

您没有误解这个问题。。。Thks