從ms-access客戶端界面切換到可執行文件

Question

是否有類似於VB，.NET或其他Microsoft技術中的ms-access表單的對象？

我們現在使用Access開發客戶端界面，在過去的兩年中取得了一些成功。我們正在使用一系列開發工具來充分利用元模型（我們有用於表單，本地查詢，菜單，控件，連接等的表），並堅持一些強大的編程技術，例如，所有可視化基本代碼都是位於模塊或類模塊中。因此，表格中保存的VB代碼已被制定爲標準，並且其生產是完全自動的，根據其類型添加了預定義的事件到控件（這已經簡要地公開了here）。

除了這些形式之外，我們使用的所有其他對象可以以某種方式從Access/mdb文件中取出：本地表可以保存爲xml文件，模塊可以導出爲可視基本文件/用另一種語言重寫。我們不使用任何宏（除'autoexec'之外），報告（我們使用Crystal Reports加載項）或查詢（存儲在「查詢」表中）

查找類似的「forms」對象另一項技術將使我們有可能分發獨立/ .exe運行時文件，而不是我們當前的.mdb文件和ms-access運行時的組合。

Answer 1

我的看法，主要答案是普通窗口的形式，或者如果你喜歡（併成爲了最新的），WPF。兩者都對數據綁定等有很好的支持，但是，它們都不能與ms-access形式直接比較。這種形式不能孤立存儲，而只能作爲程序集的一部分存在。那麼，WPF可以存在位作爲xaml更獨立，但即使如此，幾乎總是有大量代碼隱藏（這是程序集的一部分，不可拆卸）。

Answer 2

我認爲我誤解了這個問題，但在我看來，你好像在問WinForms和/或WPF。基本的.NET Windows客戶端表單。

這將是開始的地方。

http://windowsclient.net/getstarted/

至於使用哪一個，我不是真正的清除自己。於是我問

When is Windows Forms the correct choice vs WPF?

Answer 3

無論你做什麼，你都會發現你需要重新編寫這些表單，因爲沒有其他應用程序具有與MS Access相同的體系結構。 VB.NET中的WinForms並不完全相同，並且對於有經驗的MS Access開發人員有幾個陷阱。

你可能會發現最好的想法是去尋找像WPF這樣的東西，因爲它非常不同，它可以幫助開發人員專注於他們需要做的事情，而不是嘗試移植邏輯。

無論如何，目前尚不清楚業務邏輯會以何種形式存在。它們應該是簡單的前端驗證代碼，最糟糕的是一些數據綁定和事件處理。您是否仍然需要能夠基於表格自動化表單？在這種情況下，某種形式的代碼生成器會有所幫助（儘管這不是一個很好的GUI設計策略）。