使用面向对象设计的混乱..需要帮助
假设我们有一个 Order 类和 OrderManagerService 类。
Order 类：[一些状态以及作用于该状态的方法]
- Item[]
- 状态
OrderManagerService 类：[没有状态。仅以下静态方法]
- createOrder
- getOrder
问题：假设我们在后面使用关系数据库。我们的目标是更新订单状态。好吧，状态需要在数据库中更新。我关心的是 updateStatus 方法放在哪里。
- 我应该调用 OrderManagerService.getOrder 然后调用 Order.updateStatus 吗？
- 或者创建一个新方法作为 OrderManagerService.updateOrderStatus？
好吧，第一个选项似乎是封装之后的。但是，我个人不喜欢它，因为我们最终可能会从实体对象调用 DAO 层 [也许，这可能没问题]。想知道什么是正确的设计选择以及为什么？非常感谢任何帮助。
Let say we have an Order class and OrderManagerService class.
Order class: [some state and methods that act on the state]
- Item[]
- status
OrderManagerService class: [have no state. only following static methods]
- createOrder
- getOrder
Question: Let say we are using a relational DB in the back. Our goal is to update Order status. Well, the status need to get updated in the DB. My concern is where to put the updateStatus method.
- Should I call OrderManagerService.getOrder then, call Order.updateStatus?
- or create a new method as OrderManagerService.updateOrderStatus?
well, 1st option seems following encapsulation. But, personally I dont like it as we may end up calling DAO layer from entity objects [perhaps, that might be ok]. Wondering what would be a right design choice and why? any help is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
选项 2 - 创建一个新方法作为 OrderManagerService.updateOrderStatus？
为什么？
您的服务层应该封装逻辑业务工作单元，在您的情况下，UOW 是
，并且您将使用事务来划分 updateOrderStatus(...) 。并且该服务仍然是无状态的。
Option 2 - create a new method as OrderManagerService.updateOrderStatus?
Why?
Your service layer should encapsulate the logical business unit of work and in your case the UOW is
and you would demarcate the updateOrderStatus(...) with a transaction. and the service is still stateless.
我认为 OrderManagerService 应该有一个 Order 类项目的数组。这样您就可以迭代每个项目并更新其中的状态。或者，如果您正在寻找访问单个订单项，请通过 Order 类直接访问它并在那里更新它。
无论哪种情况，对于您当前的设置，
updateStatus()都应该位于 Order 类中。I think OrderManagerService should have an array of Order class items. This way you could iterate through each item and update the status there. Or if you are looking for accessing a single order item go directly to it via the Order class and update it there.
In either case with your current setup the
updateStatus()should be in the Order class.观察者模式怎么样？
updateStatus() 将位于 Order 类中，由 OrderManagerService 类观察。
每次您更改状态（或其他任何内容）时，经理都会看到它并根据需要执行一些操作（例如更新数据库中的状态）。
管理器可以在创建实例并在 getOrder() 方法中返回它时绑定到 Order。
如果订单实例被销毁，您还可以实现某种方法来解除 Manager 与订单的绑定（仅在非托管语言中需要考虑）。
How about observer pattern?
updateStatus() would be in Order class, which would be observed by OrderManagerService class.
Each time you changed status (or anyting else) Manager would see it and do some actions if needed (for example update the status in the DB).
The manager could bind to Order when creating an instance and returning it in getOrder() method.
You could also implement some method to unbind Manager from an order if an instance of the order is destroyed (concern only in unmanaged languages).
由于您的问题的标题包含“使用面向对象的设计”，我会将状态转换逻辑放在订单本身中，因为对象除了数据之外还应该封装行为。
将所有行为包含在服务中可以比作贫血域模型，这取决于您决定这是否是一件坏事——对此有很多争论。
Since the title of your question contains "using object-oriented design", I'd put the state transition logic in the Order itself because objects are supposed to encapsulate behavior in addition to data.
Having all behavior contained in Services can be likened to an Anemic Domain Model, which is up to you to decide if it's a bad thing or not - there's a lot of debate over that.
为什么有一个单独的 OrderManagerService 类？我将所有这些方法都塞进了 Order 中。
（这可能在理论上不正确或不符合四人组的设计模式，但我不在乎，因为它更有意义。）
Why is there a separate OrderManagerService class? I'd bung all those methods into Order.
(That's probably not theoretically correct or gang-of-four-compliant design pattern but I dn't care because it would make more sense.)