如何建模应用程序并使多线程需求与封装协调

Question

比方说，例如，我有一个小部件订购应用程序。它允许客户从小部件目录中订购。明显的对象选择可能是'目录'和'订单'。 'Catalog'对象将允许我浏览，添加和删除小部件。 '订单'对象将允许我创建和更新订单。

它们都是多线程安全的并且在内部处理对象锁定和数据库事务。它们被很好地封装/划分 - 直到需求出现时，说明从目录中删除小部件时，包含该小部件的行项目必须从现有订单中删除。

处理这种情况的常见方法是使用观察者模式。换句话说，当零件被删除时，从“目录”中引发事件。调解员然后处理此事件并告诉'订单'删除与该小部件的订单项。

优点：保留封装，松耦合。

缺点：是不是删除的部分和更新的订单一个单一的原子操作？这种技术会违反这一点。换句话说，如果在处理事件时发生错误，则可以在不更新任何订单的情况下移除零件。

我赞成利弊。但是，这只能意味着需要另一个对象 - 一个聚合“目录”和“订单”，并使两个操作都以原子方式执行。问题是每个对象都执行对象锁定和数据库事务，我都不知道如何清理地提取 - 也就是说，在技术上新对象应该现在处理这个责任，因为你不能锁定对象并且执行两次事务并且仍然有一个原子操作。

想法？这是我以前从未见过的经典问题吗？我一直在春天的路上，但我不认为AOP可以在这里做任何事情。

谢谢。

Answer 1

This是一个链接，描述了在GORM下不同类型的关系如何处理/级联删除和更新。看起来你所描述的设置可以建模为几个1：m或m：n的关系。 Ctrl + F代表“级联”，这应该阐明如何处理关系之间的变化以及如何对关系进行最佳建模。就错误而言，如果您提供正确的“belongsTo”关系，级联还有助于照顾这些问题。如果您想删除或更改父对象，则必须先删除/更新儿童。如果对子项所做的更改失败，则原始调用将失败，并且不会将更改持久保存到数据库。当文档在更改后引用“保存”时，它指的是永久性更改，在给定一组关系的情况下，只能在特定情况下执行永久性更改，例如子级对象已经首先删除子对象。对不起，我不能给你一个直接的答案，因为我不确定你是否试图改变你的模型风格或实现你自己的关系模型，但希望这可以帮助你一点点。据我所知，GORM应该是线程安全的。转到最上面并阅读整个“5.对象关系映射（GORM）”部分。祝你好运！