比如说，我有一个小部件订购应用程序。它允许客户从部件目录中订购。明显的对象选择可能是"Catalog"one_answers"Orders"。"Catalog"对象将允许我浏览、添加和删除小部件。'Orders'对象将允许我创建和更新订单。
它们都是多线程安全的，并且在内部处理对象锁定和数据库事务。它们被很好地封装/划分——直到出现这样的需求:当一个小部件从目录中删除时，包含该小部件的行项目必须从现有订单中删除。 处理这种情况的一种常用方法是使用观察者模式。换句话说，当部件被删除时，将从"Catalog"引发事件。然后，中介处理此事件并告诉"Orders"删除带有该小部件的行项。优点:保留封装和松耦合。
缺点:不是单个原子操作，即删除部件和更新订单。这个技术就违背了这一点。换句话说，如果在处理事件时发生错误，则可以在不更新任何订单的情况下删除该部件。
我倾向于缺点。然而，这只能意味着需要另一个对象——一个聚合'Catalog'和'Orders'的对象，并使这两个操作都自动执行。问题是每个对象都执行对象锁定和数据库事务，我不知道如何清晰地提取这两者——也就是说，从技术上讲，新对象现在应该处理这个责任，因为你不能锁定对象并执行两次事务，并且仍然具有原子操作。
想法吗?这是我以前没见过的经典问题吗?我一直在沿着Spring的道路前进，但是我不认为AOP可以在这里做任何事情。
谢谢。
这是一个描述在GORM下如何处理/级联不同类型关系的删除和更新的链接。您所描述的设置似乎可以建模为几个1:m或m:n关系。Ctrl+F表示"级联"，这应该能说明如何处理关系之间的变化以及如何最好地为关系建模。就错误而言，如果您提供了正确的"belongsTo"关系，级联还可以帮助处理这些错误。如果要删除或更改父对象，则必须首先删除/更新子对象。如果对子进程所做的更改失败，则原始调用失败，并且不会将更改持久化到数据库中。当文档提到在进行更改后"保存"时，它指的是永久性更改，对于一组关系来说，永久性更改只能在某些情况下执行，例如子对象首先被级联删除。对不起，我不能给你一个直接的答案，因为我不确定你是否试图改变你的模型风格或实现你自己的关系模型，但希望这有助于你一点。GORM应该是线程安全的，据我所知。到最上面，通读整个"5"。对象关系映射(GORM)"部分。好运！