1

这可能是一个相当新手的设计问题。我正在努力满足许多要求，并为用户提供他们正在寻找的体验......

我写了一个工具来做大的计算类型的事情。它目前由一个类库和命令行工具（单独的 .NET 项目）组成。我们使用 Access 数据库格式作为文件类型，因为它可以将所有各种表一起保存在一个文件中。关于该应用程序的其他一些项目： - 用户不多。无需担心可扩展性。- 更新没有太大问题。- 需要桌面。不是网络。- 使用 VB 和 .NET 3.5 SP1

我现在需要开发一个允许典型的文件/打开和文件/保存类型操作的 GUI 前端。

用户希望他们可以打开一个文件，对其进行一些编辑，然后选择保存或关闭它而不保存——而不会将任何更改写回文件。保存它显然会将影响所有表的所有更改保存回文件。

那么将临时文件用于代理之类的东西是否有意义？当用户“打开”文件时，将源 Access 文件复制到本地临时文件，然后将其用于编辑会话？然后，如果用户“保存”，将本地临时文件复制回源路径？

这个问题清楚吗？设计很牛逼？？？有什么意见或建议吗？

更新： [也用 ms-access 标记] 另外，我忽略了用户也期望典型的文件/另存为功能这一事实。我认为我在这篇文章中提出的设计是传统上所谓的代理设计模式。以前有没有人用 Access 数据库文件尝试过这个（成功！）？警告或建议？

4

2 回答 2

0

嗯，这种方法会奏效，但它不是世界上最伟大的设计。你所说的基本上是交易。事务是对数据库的一组原子操作，它们要么全部进入，要么都不进入。

通常，您使用 BEGIN 和 COMMIT 将事务括起来。这样，事务就不会涉及整个数据库，只涉及您当时正在处理的特定部分。

不过从你的描述很难判断。在您的情况下，可能全部或全部都可以，并且您描述的“访问文件复制技术”可以正常工作。

但是，如果用户希望打开数据库，在此处进行一些更改，提交它们，然后在此处进行一些更改然后撤消这些更改，那么它不会很好地工作。

于 2010-10-29T20:59:36.947 回答
0

我猜这个设计并不漂亮，但是如果你使用 MS Access 数据库作为一种“场景”文件来进行计算，那么这种方法最容易实现你想要的。

正如@drventure 提到的，通常您会使用事务来控制是否保存更改，但在您的应用程序中，您必须在打开访问数据库并根据用户的操作提交或放弃该事务时启动“全局”事务. 但是，我不知道 Access 如何处理一个对多个“打开”很长时间的表进行多次更改的事务......

在这两种方法中，您都必须在不关闭应用程序的情况下处理保存？对于相当简单的事务方法：提交全局事务并立即启动一个新事务。在临时文件方法中，这可能会涉及更多，因为它需要关闭并重新打开临时文件并确保保留或重新建立应用程序的状态。

于 2010-11-01T08:23:24.353 回答