RequestFactory: Advantages of using the ServiceLocator pattern

[Alexander Orlov]

I think using ServiceLocator boils down to 

"Methods that return a Request object in the client interface are implemented as static methods in the service class. Alternatively, they may be implemented as instance methods in a service object returned by a ServiceLocator."

what pretty much describes how SL works. An obvious advantage of using SL is that you don't clutter your data model classes with any related methods.

But are there further advantages of using SL (and therefore implementing not static but instance methods) vs. implementing static methods?

[Magno Machado]

I think code is better organized and has better testability if service methods are implemented as instance methods on a service class instead of static methods on the domain classes

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/EcdfWQm-gIQJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Magno Machado Paulo
http://blog.magnomachado.com.br
http://code.google.com/p/emballo/

[Alexander Orlov]

But what's about this case: This method is from a server-side entity class that has to associate it's user field with a given user (retrieved by its userId).

    public void setUser(final Integer userId) {

        this.user = User.find(userId); // this is what I need to do using the "static" way

// below is what I have to do when I'm using SL

//          MainServiceLocator mainServiceLocator = new MainServiceLocator();

//          UserDAOService userService = (UserDAOService) mainServiceLocator.getInstance(UserDAOService.class);

//          userService.find(User.class, userId)

    }

Ok, the SL could be simpler but the point is: I've to instantiate the SL in order to use the find method which could be declared static.

[Jens]

Only advantage I can see right now is that you can overwrite methods of a super class, e.g. a generic service method which may not fit well for some rare specific sub services.

If you do not need to overwrite methods in services then you are probably fine not using a ServiceLocator. Without a ServiceLocator you still have inheritance of services and you can still put all your service methods into a separate service/DAO class instead of the domain classes. You just cant overwrite methods.

-- J

[Magno Machado]

I didn't understand your exemple. Who is responsible for doing all of this stuff is the requestfactory framework, not you

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/g3VZ4gRhMA4J.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Alexander Orlov]

On Thursday, August 18, 2011 2:48:56 PM UTC+2, Magno Machado wrote:

I didn't understand your exemple. Who is responsible for doing all of this stuff is the requestfactory framework, not you

 

I haven't implemented SL for all entities. So I still rely on this static server-side method to keep the rest functional.

[Jens]

Seems somehow bad to me. Executing queries in property accessor methods doesn't feel right to me. this.user should by integer or the parameter should be a User. In case of the latter a third object (e.g. one of your services or JPA itself) should be responsible to fill in the correct user instance.

Of course in this example using a SL doesn't seem nice..but the example itself isn't really nice to me :)

[Alexander Orlov]

On Thursday, August 18, 2011 2:59:43 PM UTC+2, Jens wrote:

Of course in this example using a SL doesn't seem nice..but the example itself isn't really nice to me :)

Agree :) This is called "successively grown". 

[Alexander Orlov]

On Thursday, August 18, 2011 2:43:47 PM UTC+2, Alexander Orlov wrote:

    public void setUser(final Integer userId) {

        this.user = User.find(userId); // this is what I need to do using the "static" way

// below is what I have to do when I'm using SL

//          MainServiceLocator mainServiceLocator = new MainServiceLocator();

//          UserDAOService userService = (UserDAOService) mainServiceLocator.getInstance(UserDAOService.class);

//          userService.find(User.class, userId)

    }

I think that's better within the data model:

this.user = (User)entityController.find(User.class, userId);