Static Service Registry

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Static Service Registry

Sergei Rahouski

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.

 

Reply | Threaded
Open this post in threaded view
|

Re: Static Service Registry

sergiomichels
If I understand it's like a helper class, to minimize the content of your service? For simple helpers I tend to create static methods, passing the artefact as argument.

class AssetPaginator {
  static List getItems(AssertService service) {
    //do your helper magic...
  }
}

If you use some convention, you can have a generic helper...

static List getItems(service) {
   //consider that all services in this case have the findItems method
}





--
Sérgio Michels


On Fri, Sep 27, 2013 at 2:39 PM, Sergei Rahouski <[hidden email]> wrote:

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.

 


Reply | Threaded
Open this post in threaded view
|

RE: Static Service Registry

Sergei Rahouski

It is a bit different. AssetPaginator is the class that we “new” . It lives outside of spring. It uses assetService to get data. We are currently passing the service in every time it is created. This clutters the code, so we are looking to give Spring-awareness to the paginator using entirely static helper class SystemServices that gives a clean way to access *all* application services. It acts as a registry of the services. Using static import we can achieve the same effect as Grails gives you when it auto-injects the service to the controllers and other services.

 

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 12:55 PM
To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

If I understand it's like a helper class, to minimize the content of your service? For simple helpers I tend to create static methods, passing the artefact as argument.

 

class AssetPaginator {

  static List getItems(AssertService service) {

    //do your helper magic...

  }

}

 

If you use some convention, you can have a generic helper...

 

static List getItems(service) {

   //consider that all services in this case have the findItems method

}

 

 

 

 


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 2:39 PM, Sergei Rahouski <[hidden email]> wrote:

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Static Service Registry

sergiomichels
I see now. Isn't a better approach to make AssetPaginator a Spring Bean and let Grails handle the dependency injection for you? I think it will be more testable than having a "static registry".

--
Sérgio Michels


On Fri, Sep 27, 2013 at 3:05 PM, Sergei Rahouski <[hidden email]> wrote:

It is a bit different. AssetPaginator is the class that we “new” . It lives outside of spring. It uses assetService to get data. We are currently passing the service in every time it is created. This clutters the code, so we are looking to give Spring-awareness to the paginator using entirely static helper class SystemServices that gives a clean way to access *all* application services. It acts as a registry of the services. Using static import we can achieve the same effect as Grails gives you when it auto-injects the service to the controllers and other services.

 

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 12:55 PM
To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

If I understand it's like a helper class, to minimize the content of your service? For simple helpers I tend to create static methods, passing the artefact as argument.

 

class AssetPaginator {

  static List getItems(AssertService service) {

    //do your helper magic...

  }

}

 

If you use some convention, you can have a generic helper...

 

static List getItems(service) {

   //consider that all services in this case have the findItems method

}

 

 

 

 


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 2:39 PM, Sergei Rahouski <[hidden email]> wrote:

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.

 

 


Reply | Threaded
Open this post in threaded view
|

RE: Static Service Registry

Sergei Rahouski

We have way too many classes to make everything a bean.

 

We did think about testing the registry. You could easily mock the getAssetService() method in your tests or even come up with a setter method in the registry so you can preset or override your tests if necessary.

 

We are more worried about Grails class reloading. What would happen to the registry if Grails recompiled one of the services …

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 1:32 PM
To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

I see now. Isn't a better approach to make AssetPaginator a Spring Bean and let Grails handle the dependency injection for you? I think it will be more testable than having a "static registry".


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 3:05 PM, Sergei Rahouski <[hidden email]> wrote:

It is a bit different. AssetPaginator is the class that we “new” . It lives outside of spring. It uses assetService to get data. We are currently passing the service in every time it is created. This clutters the code, so we are looking to give Spring-awareness to the paginator using entirely static helper class SystemServices that gives a clean way to access *all* application services. It acts as a registry of the services. Using static import we can achieve the same effect as Grails gives you when it auto-injects the service to the controllers and other services.

 

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 12:55 PM
To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

If I understand it's like a helper class, to minimize the content of your service? For simple helpers I tend to create static methods, passing the artefact as argument.

 

class AssetPaginator {

  static List getItems(AssertService service) {

    //do your helper magic...

  }

}

 

If you use some convention, you can have a generic helper...

 

static List getItems(service) {

   //consider that all services in this case have the findItems method

}

 

 

 

 


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 2:39 PM, Sergei Rahouski <[hidden email]> wrote:

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Static Service Registry

sergiomichels
That's a good question, I don't know how Grails will handle that. Maybe in the development mode it would be better to always return the instance from the grailsApplication, something like:

class MyRegistry {

  private static Map<String, Object> registry

  static AssetService getAssetService() {
    getBean('assetService')
  }

  static getBean(String beanName) {
    if(Environment.current == Environment.DEVELOPMENT) {
      return Holders.grailsApplication.mainContext.getBean(beanName)
    } else {
      def bean = registry[beanName]
      if(!bean) {
        bean = Holders.grailsApplication.mainContext.getBean(beanName)
        registry[beanName] = bean
      }
      return bean
    }
  }

}




--
Sérgio Michels


On Fri, Sep 27, 2013 at 3:44 PM, Sergei Rahouski <[hidden email]> wrote:

We have way too many classes to make everything a bean.

 

We did think about testing the registry. You could easily mock the getAssetService() method in your tests or even come up with a setter method in the registry so you can preset or override your tests if necessary.

 

We are more worried about Grails class reloading. What would happen to the registry if Grails recompiled one of the services …

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 1:32 PM


To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

I see now. Isn't a better approach to make AssetPaginator a Spring Bean and let Grails handle the dependency injection for you? I think it will be more testable than having a "static registry".


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 3:05 PM, Sergei Rahouski <[hidden email]> wrote:

It is a bit different. AssetPaginator is the class that we “new” . It lives outside of spring. It uses assetService to get data. We are currently passing the service in every time it is created. This clutters the code, so we are looking to give Spring-awareness to the paginator using entirely static helper class SystemServices that gives a clean way to access *all* application services. It acts as a registry of the services. Using static import we can achieve the same effect as Grails gives you when it auto-injects the service to the controllers and other services.

 

 

From: Sergio Michels [mailto:[hidden email]]
Sent: Friday, September 27, 2013 12:55 PM
To: [hidden email]
Subject: Re: [grails-user] Static Service Registry

 

If I understand it's like a helper class, to minimize the content of your service? For simple helpers I tend to create static methods, passing the artefact as argument.

 

class AssetPaginator {

  static List getItems(AssertService service) {

    //do your helper magic...

  }

}

 

If you use some convention, you can have a generic helper...

 

static List getItems(service) {

   //consider that all services in this case have the findItems method

}

 

 

 

 


--

Sérgio Michels

 

On Fri, Sep 27, 2013 at 2:39 PM, Sergei Rahouski <[hidden email]> wrote:

Hi all,

 

In our application we often need to access spring beans from classes created outside of spring (in src/groovy). We’ve used custom injection methods to initialize these objects before they are used from controllers and services in Grails.

 

class AssetService {

  ..

  def  createPaginator() {

    return new AssetPaginator(this, filterOptions)

  }

  …

}

 

We now have a different idea of handling this application to use registry static class that will use ApplicationHolder.application to look up services in spring context.

 

class SystemServices {

 

   private static AssetService _assetService

 

   static AssetService getAssetService() {

     __assetService = _assetService ?: ApplicationContextHolder.application.mainContext.getBean(AssetService)

   }

}

 

Later on this class can be used as a static import in paginator:

 

import static SystemServices.getAssetService

 

class AssetPaginator {

  // def assetPaginator – not needed

 

  List getItems() {

     assetService.findItems()

  }

}

 

We don’t see anything wrong with this approach. However it seems disconnected enough from what Grails is doing to make us nervous.

 

What do you think about this approach ? What are the things that could go wrong? Your general opinion on this … ?

 

Thank you all.