当我掉下grails服务的麻烦时，我目前正在将业务逻辑从控制器方法转移到服务中。我在服务中使用以下方法：
Job closeJobOpportunity(Job op, Employee res) {
op.chosenOne = res
op.requisitionCanceledDate = new Date()
if(!op.chosenOne || !op.hrEffectiveDate){
return null
}
else if(StringUtils.isEmpty(op.chosenOne.id)){
return null
}
return op
}
我开始考虑这种方法可能导致同步问题的不同方式（因为grails使服务成为单例），并注意到grails文档提到只要您不存储状态，就应该将业务逻辑放入服务中。
冒着听起来无知或消息不充分的风险，有人可以简单地在Grails中提供有状态服务与无状态服务之间的区别吗？上面的方法有状态吗？然后是否应将其插入控制器中的try catch中？
Grails服务（或与此相关的类的任何其他实例）中的有状态和无状态之间的差异取决于实例本身是否具有任何状态。
首先，很难说出示例中的Service是否为无状态，但是在该特定方法中进行的交互并不表示您对服务本身进行了有状态的操作。那会让我相信该服务将是无状态的。
让我给您提供一个有状态服务的示例，并解释为什么它是有状态的。
class MyStatefulService {
Long someNumber
String someString
void doSomething(Long addMe) {
someNumber += addMe
}
void updateSomething(String newValue) {
someString = newValue
}
}
如您所见，以上服务具有两个属性。如果将此服务创建为单例，则对其的所有调用都将使用相同的单个实例。如您所见，服务上的两种方法会影响服务的属性或状态。这意味着，以当前形式，您不能确定特定线程正在执行服务的一个或多个方法时状态不会改变。以目前的形式，使其不可靠。尽管这是一个非常简单的示例，但它确实演示了使服务有状态的原因。
服务具有属性是可以的，并且通常它们也可以。它们可以是对其他服务甚至配置值的引用。关键概念是确保它们不更改状态（总是存在例外，但这是边缘情况）。
完全有可能将服务重写为有状态的，同步的，这样可以避免多个线程访问和修改状态的陷阱，但这不是您的目标。无状态服务更简单，更简洁，更容易测试，更容易调试以及更轻便。
简而言之，使您的服务成为无状态的服务，并省去您的头痛。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句