使用 MS Access 数据库作为需要打开/保存类型功能的桌面应用程序的文件格式
这可能是一个相当新手的设计问题。我正在努力满足许多要求，并为用户提供他们正在寻找的体验...
我编写了一个可以执行大型计算类型操作的工具。它当前由一个类库和命令行工具（单独的 .NET 项目）组成。我们使用 Access 数据库格式作为文件类型，因为它可以将所有不同的表保存在一个文件中。有关该应用程序的其他一些事项： - 用户不多。无需担心可扩展性。 - 更新方面没有太大问题。 - 需要桌面。不是网络。 - 使用 VB 和 .NET 3.5 SP1
我现在需要开发一个 GUI 前端，该前端将允许典型的文件/打开和文件/保存类型操作。
用户希望他们可以打开一个文件，对其进行一些编辑，然后选择保存它或在不保存的情况下关闭它——而不会将任何更改写回到文件中。保存它显然会将影响所有表的所有更改保存回文件。
那么使用临时文件作为代理之类的东西有意义吗？当用户“打开”文件时，将源 Access 文件复制到本地临时文件，然后将其用于编辑会话？那么，如果用户“保存”，是否将本地临时文件复制回源路径？
这个问题清楚吗？设计很糟糕吗？？？有什么意见或建议吗？
更新： [也用 ms-access 标签标记] 另外，我忽略了用户也期望典型的文件/另存为功能这一事实。我认为我在这篇文章中提出的问题是传统上所谓的代理设计模式。以前有人尝试过使用 Access 数据库文件（成功！）吗？警告或建议？
This is probably a pretty novice design question. I'm trying to work my way through a number of requirements and give the users the experience they're looking for...
I've written a tool that does big calcluation-type things. It currently consists of a class library and command line tool (separate .NET projects.) We're using an Access database format as the file type because it can keep all the various tables together in one file. A few other items about the application:
- There are not many users. There are no concerns with scalability.
- There are not great concerns with updates.
- Desktop is desired. Not web.
- Using VB and .NET 3.5 SP1
I now need to develop a GUI front end that will allow typical File/Open and File/Save type operations.
Users expect that they can open a file, edit it some, then either choose to save it or close it unsaved -- without any changes being written back to the file. Saving it would obviously save all changes affecting all tables back to the file.
Does it then make sense to use a temp file for something like a proxy then? To, when a user "opens" a file, copy the source Access file to a local temp file and then use that for the editing session? Then, if the user "saves", copy the local temp file back to the source path?
Is that question clear? Is the design horrid??? Any comments or suggestions?
Update: [tagged with ms-access tag too] Also, I omitted the fact that users would expect typical File / Save As functionality too. I think the design I've put in question in this post is what is traditionally called the Proxy design pattern. Has anyone tried this (successfully!) with Access database files before? Words of caution or advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
嗯，这种方法可行，但它不是世界上最伟大的设计。
基本上，您所说的是交易。事务是对数据库的一组原子操作，要么全部执行，要么都不执行。
通常，您用 BEGIN 和 COMMIT 将事务括起来。这样事务就不会涉及整个数据库，只涉及您当时正在处理的特定部分。
不过从你的描述中很难判断。在您的情况下，也许全部或全部都没有问题，并且您描述的“访问文件复制技术”会很好地工作。
但是，如果用户希望打开数据库，在这里进行一些更改，提交它们，然后在那里进行一些更改，然后撤消这些更改，那么它不会很好地工作。
Well, that approach would work, but it's not the greatest design in the world.
What you're talking about is transactions, basically. A transaction is a set of operations to a database that are atomic, either they ALL go in or none of them do.
Usually, you bracket a transaction with a BEGIN and a COMMIT. That way the transaction doesn't involve the entire database, only the specific parts you're working on right then.
Hard to tell from your description though. In your case, maybe all or nothing would be ok, and the "access file copy technique" you describe would work fine.
But if the user expects to open the DB, make a few changes over here, commit them, then make a few changes over there and then undo those, it won't work well for that.
我猜这个设计并不漂亮，但如果您使用 MS Access 数据库作为计算的一种“场景”文件，那么这种方法是最容易实现您想要的。
正如 @drventure 提到的，通常您会使用事务来控制是否保存更改，但在您的应用程序中，您必须在打开访问数据库时启动“全局”事务，并根据用户的操作提交或放弃该事务。但是，我不知道 Access 如何执行处理长时间“打开”的多个表上的多个更改的事务...
在这两种方法中，您都必须在不关闭应用程序的情况下处理保存？对于事务方法来说，这相当简单：提交全局事务并立即启动一个新事务。在临时文件方法中，这可能会涉及更多一些，因为它需要关闭并重新打开临时文件并确保保留或重新建立应用程序的状态。
The design isn't pretty I guess, but if you are using an MS Access database as a sort of "scenario" file for your calculations then this approach is the easiest to achieve what you want.
As @drventure mentioned, normally you would use transactions to control whether changes get saved or not, but in your app you would have to start a "gobal" transaction upon opening the access database and committing or abandoning that transaction depending on what the user does. I have no idea however, how Access performs handling a transaction with multiple changes on multiple tables that is "open" for a long time...
In both approaches you would have to deal with saves without closing the app? In the case of the transaction approach that is fairly simple: commit the global transaction and and immediately starting a new one. In the temporary file approach this could be a little more involved, as it would require closing and reopening the temporary file and making sure that the state of the application is preserved or re-established.