每个州一个命令，或者一个命令统治所有州
我正在努力分析我正在研究的问题。我处理一个清洁应用程序，其中安排清洁，然后由一些企业完成，最后由房屋所有者控制。
当企业完成其职责时，它必须向应用程序发送一条命令，告诉应用程序：
- 工作已完成（开始日期、结束日期） 工作
- 未完成，完全是我们的错（注释）
- 工作未完成，但这是我们的错所有者 (ReasonId)
其中每个可能使用不同的信息。所以我正在考虑使用 3 个不同的命令来对其进行建模，而不是只使用一个命令并添加一个状态。
但复杂性又高了一层，因为企业可能执行 3 种主要的清洁类型，并且对于其中的每一种，您可能需要向这些命令中添加不同的内容（例如：要清洁的座位数量、或区域和描述） ）。
仅此而已，我就已经有 9 个案例需要处理了。我觉得将所有这些解耦是正确的方法，因为它可以在未来提供更大的灵活性。
是否正确地认为这 3 个是不同的东西，它们不应该只是一个大命令，例如：
- 我告诉你我们做了什么（StateOfWork、StartDate、EndDate、Comment、ReasonId、NbSeat、AreaQuantity、AreaDescription...）
但是我 不喜欢有一个物体半满的想法，因为它涵盖了太多的东西。
感谢您的阅读和您的想法，
I am struggling with the analysis of a problem I am working on. I deal with a cleaning app where cleaning are scheduled, then done by some enterprise and finally controlled by the owner of the premises.
When the enterprise has done its part, it must send a command to the application telling either:
- the job was done (StartDate,EndDate)
- the job was not done totally our fault (Comment)
- the job was not done but it is the fault of the owner (ReasonId)
each of these might use different informations. So I was thinking of using 3 different commands to model it instead of having only one and adding a state.
But there is one level more of complexity , because there are 3 major kind of cleaning that an enterprise might perform and foreach of these, you might have different things to add to these commands (eg: number of seats to clean, or area and description).
Just with this it makes me already 9 cases to handle. I sense that decoupling all these is the right way to go because, it enables then more flexibility in the future.
But am I right thinking that these 3 are different things, should they not be only one big command like :
- I Tell you what we did (StateOfWork, StartDate,EndDate,Comment,ReasonId, NbSeat, AreaQuantity, AreaDescription...)
I quite do not like the thought of having an object half full because it covers too much things..
Thanks for your reading and your thoughts,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您已经为解耦方法提供了很好的案例 - 关注点分离是一个很好的使用原则。
如果每个命令具有不同的含义，则应将其建模为不同的对象。
如果将每个状态更改建模为不同的对象，则您将获得事件日志，并且如果您需要它，事件源< /a>.
拥有（至少）8 个参数的方法是一种代码味道 - 它告诉我该方法做了太多事情，最终会变得非常复杂且难以维护。
You have made a good case for the decoupled approach - separation of concerns is a good principle to use.
If each command has a different meaning it should be modelled as a different object.
If you model each state change as a different object, you are on the way to having an event log and if you need it, event sourcing.
Having a method with (at least) 8 parameters is a code smell - it tells me the method does too much and will end up being very complex and difficult to maintain.