我正在开发销售推广系统,我刚刚踩到了一些可能可以用状态机模式处理的东西,但我还没有使用状态机的经验。也许状态机在这种情况下完全没有用:)所以我有一个促销活动,它有一些持续时间,一些指定的客户,产品,折扣等。每个促销活动也有它的状态。大概有5个州。状态之间的转换是严格定义的-不可能直接将状态1更改为状态3-用户必须首先将状态更改为2。有一些限制,比如“当促销处于3-5状态时,不可能添加更多的产品”。或者像“只有超级用户才能编辑处于3-5状态的促销费用”这样的限制。
我刚刚读到了http://www.codeplex.com/SimpleStateMachine,但我不确定对于这个案例来说它是否太复杂了。我可以在我的服务层中使用如下内容来处理状态逻辑:
if (promotion.state == statesRepository.GetState3() && false == loggedUser.IsInRole("superUser")){
throw new PromotionStateException("user not allowed to edit promotion in this status");
}
...
或
public void ChangePromotionStatus(promotion, newStatus){
if (promotion.Status == status1 && newStatus != statesRepo.GetState2()){
throw new StateTransitionException("unable to change from status 1 to " + newStatus);
}
}
但我不喜欢这种代码--肯定有更好的方法:)有人有什么建议吗?当然,我可以分离这些关注点,开发PromotionStatusChangeReviewService、PromotionEditPermissionService等服务来减少代码的耦合性,但目前可能还没有更好的解决方案。
发布于 2009-03-23 14:23:16
对于状态机来说,五个状态并不是太复杂,但我认为,尝试特殊或显式地处理一些转换会遇到一些问题。这里有一些小贴士:
除非您能够以一种有意义的方式标记状态,否则
ChangePromotionStatus()
这样的方法,例如,如果不允许状态,它就会爆炸。状态机应该简单地防止不可能发生的转换。发布于 2009-03-27 19:33:02
John一针见血--您希望使用状态机建模的流程与领域实体解耦。您的领域实体可能不应该直接知道它们正在状态机中使用,状态机将根据特定事件管理将它们从一个状态转换到另一个状态的工作,但是它们将理解它们所处的每个状态的业务含义,并能够强制或应用与这些状态相关的业务规则。
理想情况下,适合由状态机管理的域实体将具有某种状态,该状态充当状态机的状态,并将引发可由状态机使用的事件,以确定何时进行适当的转换。
然而,如果你的状态确实是完全连续的--即它们总是在a-b-c-d-e或前后移动一步,我不确定状态机是否有意义,因为选择下一个状态不需要特殊的上下文-你只能后退或前进,所以任何有序的状态列表(比如枚举)加上下一个/上一个逻辑应该就足够了-但是现实世界的过程很少是那么严格的线性的,即使它们看起来可能是第一次刷新。
https://stackoverflow.com/questions/673535
复制相似问题