如何对应用程序进行建模并使多线程需求与封装相协调
举例来说，我有一个小部件订购应用程序。它允许客户从小部件目录中订购。明显的对象选择可能是“目录”和“订单”。 “目录”对象将允许我浏览、添加和删除小部件。 “订单”对象将允许我创建和更新订单。
它们都是多线程安全的，并在内部处理对象锁定和数据库事务。它们被很好地封装/分隔——直到出现一个要求，即从目录中删除某个小部件时，必须从现有订单中删除包含该小部件的行项目。
处理这种情况的常见方法是使用观察者模式。换句话说，当删除部分时，会从“目录”引发一个事件。然后，调解器处理此事件并告诉“订单”删除带有该小部件的行项目。
优点：保留封装性、松散耦合。
缺点：部件的移除和订单的更新不是单个原子操作吗？这项技术会违反这一点。换句话说，如果处理事件时发生错误，则该部件可能会被删除，而不会更新任何订单。
我赞成缺点。然而，这只能意味着需要另一个对象——一个聚合“目录”和“订单”的对象，并导致这两个操作以原子方式执行。问题是每个对象都执行对象锁定和数据库事务，我都看不到如何干净地提取这两者 - 即，从技术上讲，新对象现在应该处理该责任，因为您不能锁定对象并执行事务两次并且仍然具有原子操作。
想法？这是我以前没见过的经典问题吗？我一直在走 Spring 之路，但我认为 AOP 在这里无能为力。
谢谢。
Lets say, for example, I have a widget ordering application. It allows customers to order from a catalog of widgets. Obvious object choices might be 'Catalog' and 'Orders'. The 'Catalog' object will allow me to browse, add and delete widgets. The 'Orders' object will allow me to create and update orders.
They are both multi-thread safe and handle object locking and database transactions internally. They are nicely encapsulated/compartmentalized -- until a requirement comes along that says when a widget is deleted from the catalog, line items containing that widget must be deleted from existing orders.
A common way to handle this scenario is with the observer pattern. In other words, an event is raised from 'Catalog' when part is deleted. A mediator then handles this event and tells 'Orders' to remove line items with that widget.
The pros: preserves encapsulation, loose coupling.
The cons: are not the removal of the part and the update of the orders a single, atomic operation? This technique would violate that. In other words, if an error happens handling the event, the part may be removed without ever updating any orders.
I am favoring the cons. However, this can only mean that another object is required -- one that aggregates 'Catalog' and 'Orders', and causes both operations to be performed atomically. The problem is each object performs object locking and database transactions, neither of which I can see how to cleanly extract -- ie, technically the new object should handle that responsibility now because you cannot lock objects and perform transactions twice and still have an atomic operation.
Thoughts? Is this a classic problem I've not seen before? I've been down the Spring road but I don't think there's anything AOP can do here.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
此是一个描述 GORM 下如何针对不同类型的关系处理/级联删除和更新的链接。您所描述的设置似乎可以建模为一些 1:m 或 m:n 关系。 Ctrl+F 用于“级联”，这应该有助于了解如何处理关系之间的变化以及如何最好地对关系进行建模。就错误而言，如果您提供了正确的“belongsTo”关系，级联也有助于处理这些错误。如果要删除或更改父对象，则还必须首先删除/更新子对象。如果对子项所做的更改失败，则原始调用将失败，并且不会将任何更改保留到数据库中。当文档提到更改后“保存”时，它指的是永久性更改，在给定一组关系的情况下，只能在某些情况下执行，例如子对象已首先被级联删除。抱歉，我无法给您直接答案，因为我不确定您是否正在尝试更改模型样式或实现您自己的关系模型，但希望这对您有所帮助。据我所知，GORM 应该是线程安全的。转到最顶部并阅读整个“5. 对象关系映射 (GORM)”部分。祝你好运！
This is a link describing how deletes and updates are handled/cascaded for different types of relationship under GORM. It appears that the setup you have described could be modeled as a few 1:m or m:n relationships. Ctrl+F for "cascading" and this should shed some light on how changes between relationships are handled and how to best model the relationships. As far as errors are concerned, cascading also helps take care of these given you provide the correct "belongsTo" relationships. If you want to delete or change a parent object, the children must first be deleted/updated as well. If the changes made to the children fail, the original call fails, and no changes are persisted to the database. When the documentation refers to "saving" after making a change, it refers to permanent changes, which, given a set of relationships, can only be performed under certain circumstances, such as child objects having been deleted first by the cascade. Sorry I can't give you a direct answer as I'm not sure if you're trying to change your model style or implement your own relational model, but hopefully this helps you out a bit. GORM should be thread safe as far as I remember. Go to the very top and read through the entire "5. Object Relational Mapping (GORM)" section. Good luck!