工作单元 - 在网络场上临时对象存储的最佳方法是什么？
我需要设计和实现类似于 Martin Fowler 所说的“工作单元”模式的东西。我听其他人将其称为“购物车”模式，但我不相信需求是相同的。
具体问题是用户（和我们的 UI 团队）希望能够在创建父对象之前创建和分配子对象（具有数据库中的引用完整性约束）。今天我会见了我们的另一位设计师，我们提出了两种替代方法。
a) 首先，在数据库中创建一个虚拟父对象，然后创建虚拟子对象和虚拟分配。我们可以使用负键（我们的正常键都是正键）来区分数据库中的绵羊和山羊。然后，当用户提交整个交易时，我们必须更新数据并添加和对齐真实的密钥。
我发现这个有几个缺点。
- 它会对指数造成干扰。
- 我们仍然需要想出一些办法来满足对具有它们的列的独特约束。
- 我们必须修改大量现有的 SQL 和生成 SQL 的代码，以便向大量 WHERE 子句添加另一个谓词。
- 更改 Oracle 中的主键是可以完成的，但这是一个挑战。
b) 为需要能够参与这些反向事务的对象和分配创建临时表。当用户点击提交时，我们生成真实的条目并清除旧的。
我认为这比第一个替代方案更干净，但仍然涉及增加数据库活动级别。
如果在用户执行提交或取消请求之前会话丢失，这两种方法都要求我有某种方法使瞬时数据过期。
有没有人以不同的方式解决这个问题？
预先感谢您的帮助。
I need to design and implement something similar to what Martin Fowler calls the "Unit of Work" pattern. I have heard others refer to it as a "Shopping Cart" pattern, but I'm not convinced the needs are the same.
The specific problem is that users (and our UI team) want to be able to create and assign child objects (with referential integrity constraints in the database) before the parent object is created. I met with another of our designers today and we came up with two alternative approaches.
a) First, create a dummy parent object in the database, and then create dummy children and dummy assignments. We could use negative keys (our normal keys are all positive) to distinguish between the sheep and the goats in the database. Then when the user submits the entire transaction we have to update data and get the real keys added and aligned.
I see several drawbacks to this one.
- It causes perturbations to the indexes.
- We still need to come up with something to satisfy unique constraints on columns that have them.
- We have to modify a lot of existing SQL and code that generates SQL to add yet another predicate to a lot of WHERE clauses.
- Altering the primary keys in Oracle can be done, but its a challenge.
b) Create Transient tables for objects and assignments that need to be able to participate in these reverse transactions. When the user hits Submit, we generate the real entries and purge the old.
I think this is cleaner than the first alternative, but still involves increased levels of database activity.
Both methods require that I have some way to expire transient data if the session is lost before the user executes submit or cancel requests.
Has anyone solved this problem in a different way?
Thanks in advance for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不明白为什么需要在提交事务之前在数据库中创建这些对象，因此您可能需要在继续解决方案之前与 UI 团队进行澄清。您可能会发现他们想做的就是读取用户先前在另一个页面上保存的信息。
因此，假设在提交之前不需要将对象存储在数据库中，我给您提供计划 C：将
初始化的业务对象存储在会话中。然后，您可以创建所需的所有子项，并且仅在需要提交事务时才接触数据库（并设置引用）。如果会话数据很大（单独或集体），请将会话信息存储在数据库中（您可能已经这样做了）。
I don't understand why these objects need to be created in the database before the transaction is committed, so you might want to clarify with your UI team before proceeding with a solution. You may find that all they want to do is read information previously saved by the user on another page.
So, assuming that the objects don't need to be stored in the database before the commit, I give you plan C:
Store initialized business objects in the session. You can then create all the children you want, and only touch the database (and set up references) when the transaction needs to be committed. If the session data is going to be large (either individually or collectively), store the session information in the database (you may already be doing this).