我们有一个 MVC Web 应用程序，它有一个索赔管理向导（类似于典型的订单条目）。声明可以有多个项目，每个项目可以有多个与之相关的文件。
声明 --> 项目 --> 文件
在添加新声明时 - 我们希望允许用户向其中添加一个或多个项目，并允许为这些项目上传文件。但是我们希望将所有内容都保存在内存中，直到实际保存 Claim - 这样如果用户没有完成 Claim 条目或丢弃它，则不会进行数据库交互。
我们能够通过会话处理数据级别的内存管理。我们在 session 中序列化 Claim 对象（也包括 Claim.Items 属性）。但是如何管理文件？
我们将文件存储在 < ClaimID >\< ItemID > 文件夹中，但是在内存中创建新声明时，在将记录保存在数据库中之前，我们没有任何 ID（两者都是自动增量 int）。
目前，我们必须限制用户在保存声明之前上传文件。
为什么不与数据库交互？听起来您打算在对应用程序的多个请求之间持久化数据，而数据库对此很有用。
您不必将它与更长期的持久化数据持久保存在同一个表中，甚至是同一个数据库实例中。也许为“瞬态”数据创建表或数据库，或者在达到特定状态之前不打算长期保存的数据。或者可能将其存储在与长期数据相同的表中，但以其他方式跟踪状态以将其标记为“不完整”或以其他方式暂时的。
您可以有一个不时清理旧数据的离线进程。如果删除对长期数据表的成本很高，那么这将是将临时数据移动到它们自己的表的一个很好的理由，随着时间的推移，针对大量写入/删除与大量读取进行了优化。
或者，您可以使用内存中对象的临时 ID 将它们与磁盘上的文件相关联，然后再将它们持久化到数据库中。甚至可能将文件关联 ID 与记录的主 ID 分开。（我假设您使用自动递增整数作为主键，这就是您需要从数据库中获取的 ID。）
例如，您可以在记录上有另一个标识符Guid（uniqueidentifier在 SQL 中），以便将记录链接到磁盘上的文件。这样，您可以在内存中创建标识符并将其保存到数据库中，而无需最初与数据库交互来生成 ID。这还具有额外的好处，即能够与不同的文件重新关联，或者根据需要更改该标识符，而不会弄乱密钥。
在许多情况下，不应将AGuid用作主键，因此您可能不想走那条路。但是拥有一个单独的 ID 可以解决问题。