【问题标题】:Uploading photos using Grails Services使用 Grails 服务上传照片
【发布时间】:2014-01-22 14:27:55
【问题描述】:

我想问一下,我在 Grails 中的上传照片服务最适合的范围是什么?我在我的 Grails 2.3.4 Web 应用程序中创建了这个 PhotoService,它所做的只是获取 request.getFile("myfile") 并在用户想要上传图像时执行必要的步骤将其保存在硬盘上。为了说明它的样子,我给出了这些类的骨架。

PhotoPageController {

    def photoService

    def upload(){
       ...
       photoService.upload(request.getFile("myfile"))
       ...
    }
}

PhotoService{

     static scope="request"
     def upload(def myFile){
        ...
        // I do a bunch of task to save the photo 
        ...
     }
}

上面的代码不是确切的代码,我只是想展示一下流程。但我的问题是:

问题: 我找不到这些不同 grails 范围的确切定义,它们有一个单一的解释,但我无法弄清楚请求范围是否意味着对控制器的每个请求都注入一个 bean,或者每次请求上传控制器的动作?

想法: 基本上由于许多用户可能同时上传,使用单例范围不是一个好主意,所以我猜我的选择是原型或请求。那么其中哪一个运行良好,哪一个仅在仅访问 PhotoService 时创建?

我试图最小化注入到应用程序上下文中的服务数量,并且只要 Web 应用程序处于活动状态就一直存在,基本上我希望服务实例在 Web 应用程序生命周期的某个时间点终止或进行垃圾收集时间,而不是在没有用的时候徘徊在记忆中。我正在考虑将其设置为会话范围,因此当用户的会话终止时,服务也会被清理,但在某些情况下,用户可能不想上传任何照片,并且无缘无故地创建了服务。

P.S:如果我在上传()中移动“def photoService”,是否只会在调用上传请求时注入它?我认为这可能会引发异常,因为在 Spring 注入服务之前会有延迟,然后对 def photoService 的引用将是 n

【问题讨论】:

    标签: scope image-uploading grails-2.0 grails-services


    【解决方案1】:

    我发现单例范围会很好,因为我没有维护每个请求/用户的状态。只有当服务应该保持状态时,我们才能继续使用原型或其他合适的范围。如果您认为单例可能会导致意外行为,那么使用原型会更安全,但这要留待测试。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-10-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-10-01
      • 1970-01-01
      • 2010-09-12
      相关资源
      最近更新 更多