在创建数据库实体之前临时存储图像的最佳实践是什么？
我正在使用 ASP.NET 4.0，并且有一个代表单个业务实体的大型 Web 表单。用户可以上传与实体关联的多个图像。提交表单后，实体将被创建并分配一个 GUID。文件将存储到文件系统中。
问题是我们必须以实体插入数据库后分配给该实体的 GUID 来命名文件。因此，在单击提交按钮之前，我们将有几个图像文件悬而未决。
这个问题有明显的答案——您将图像保存到文件系统，然后在创建业务实体时重命名这些文件。然而，我相信必须有非常强大的模式和几个关键细节才能构成一个非常强大的系统。这种情况的最佳实践是什么？
I'm working in ASP.NET 4.0, and I've got a large web form which represents a single business entity. A user can upload multiple images associated with the entity. The entity is created and assigned a GUID upon submitting the form. The files will be stored to a file system.
The problem is that we have to name the files after the GUID that is assigned to the entity after it is inserted to the database. So before the submit button is clicked, we will have several image files floating around in limbo.
There are obvious answers to this question -- you save the images to the file system and then when the business entity is created, you rename those files. However, I believe that there must be very strong patterns and several key details that would make for a very robust system. What's best practice for this scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
GUID 的优点之一是可以在任何地方创建它们。因此，让您的应用程序创建并分配 GUID，然后使用预先分配的 GUID 对实体执行插入。然后，您的应用程序将具有用于命名文件的 GUID。
如果这不可行，那么在我看来，您的重命名方案似乎是最好的选择。
One of the nice things about GUIDs is that they can be created anywhere. So have your app create and assign the GUID and then perform the insert on the entity with the pre-assigned GUID. Your app then has the GUID to use in naming the file.
If this isn't feasible then your renaming scheme seems to me to be about the best bet.
我只是在您提到“非常强大的系统”时才写这篇文章：
我会尝试防止维护数据库（包括文件系统）以外的任何状态，因为从长远来看，它会产生更多的维护复杂性。无论如何，你必须花一些时间清理文件，我更愿意从数据库中清理它。
文件系统（在大多数情况下）并不理想，因为它不
（大多数时候）
备份您的数据库，您的文件将是
也许这并不是
您正在寻找的答案，因为您可能无法更改您的需求（如果不能更改，很抱歉），但正如您提到的要使系统“非常强大”，我认为这是可能相关。
如果您使用的是 SQL 2008，请查看 FILESTREAM：
http://technet.microsoft.com/en-us/library/bb933993.aspx
I'm only writing this as you mentioned 'very robust system':
I would try to prevent maintaining any state other than in your database (that includes the file system), as it creates more maintenance complexity in the long run. You have to clean files up some time anyway, I'd prefer to clean it up from the database.
File system is (in most cases) not ideal as it does not:
(most of the time)
backup of your DB, your files will be
in 'Limbo' too
Maybe this is not really the answer you're looking for as you might not be able to change your requirements (sorry if it is not), but as you mentioned to make a system 'very robust' I thought this might be relevant.
If you're using SQL 2008, have a look at FILESTREAM:
http://technet.microsoft.com/en-us/library/bb933993.aspx
就我个人而言，我不会将上传的内容保存在文件系统中，而是将它们移动到数据库中。这样，您在备份和灾难恢复计划中就可以减少需要担心的资源，从而降低复杂性，从而减少维护。我过去的做法是，文件上传后将其保存在文件服务器上，然后在提交并接受表单后将其复制到数据库，然后从文件系统中删除它。还有一个定期维护脚本，可以清理“limbo”文件夹中的任何孤立文件。
Personally, I would stay away from saving the uploads in the file system, and instead move them to the DB. That way you would have one less resource to worry about in your backup and disaster recovery plans, thus less complexity thus less maintenance. The way I used to do it was to save the files on the file server once they are uploaded, then copy them to the DB once the form is submitted and accepted, then delete it from the file system. There would also be a regular maintenance script that cleans up the "limbo" folder of any orphaned files.