Diseño de servicios

[Jonathan Vila López]

Hola

Tengo una duda de diseño......

Estoy migrando una aplicacion hecha usando el patron "cascoporro" a un diseño mas "elegante"...... para esta migracion estoy usando OSGi, OpenJPA, Karaf, Camel, CXF, JAX-WS etc y ya que me pongo tambien Lombok que parece que mola.

Pues bien, tengo un conjunto de servicios que son los encargados de dialogar con la persistencia. Pongamos que tengo 5 servicios.

Uno de los servicios es HotelService que tiene varios metodos relacionados con los hoteles. 

Tiene los metodos publicos : getHotelsByAddress(Address address), getHotelsByZone(List<Zone>), getHotelDescription(String code) ....

Estos metodos se acostumbran a componer de varios otros metodos privados , por ejemplo : getHotelsByAddressQuery, getHotelsByAddressListOfHotelsCodes, etc....

Todo bien hasta aqui ( mas o menos ).

El tema esta en que para cada consulta de hoteles, por ejemplo aunque es para todos los metodos de todos los servicios, interviene aparte de la consulta en si tambien QUIEN la realiza : Requestor.

Entonces tomando como ejemplo el metodo getHotelsByAddress(Address address) deberiamos añadir el argumento Requestor requestor, y quedaria asi getHotelsByAddress(Requestor requestor, Address address ) 

El problema empieza cuando en realidad el Requestor se usara tambien en casi todos los metodos privados.

Lo facil seria usar pasar el Requestor tambien como argumento en todos los metodos privados, pero no me gusta.

Otra opcion seria de alguna forma crear una instancia nueva cada vez y que el servicio no fuese singleton y pasar el requestor en el constructor.....

Que opciones veis ?

[Sergi Martínez]

Patron "cascoporro". I love it.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-ju...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Sergi Martínez

sergi.m...@gmail.com

http://sergiandreplace.com

[Esteve Camps Chust]

Quizás el servicio necesite un contexto, teniendo hoy el requestor y mañana otros parametros (sin llegar a q esto sea un cajón desastre).

[Max Pimm]

Requestor suena como un candidato para Dependency Injection, @RequestScoped quizás.

[Loïc Prieto]

Estoy de acuerdo con Max. Requestor suena a concepto transversal. O bien inyectado como request scope, o bien incluso tratado mediante decoradores/interceptores si solo es una cuestión de autorización y permisos de acceso al código.

Si es para los datos que contiene requestor si que intentaría inyectarlo de alguna forma, ya sea directamente, ya sea con un servicio que lo recupere, pero en ningún caso iría pasando ese objeto hacia abajo en cada invocacion de método.

[David Villacampa]

En un singleton, solo otro singleton debería injectarse, Requestor no es candidata pk no creo k sea un Singleton

Saludos,

Salutacions / Best regards,

David Villacampa

-------- Missatge original --------
De: Max Pimm <max...@gmail.com>
Data: 04/04/2014 7:45 (GMT+01:00)
A: barcel...@googlegroups.com
Assumpte: Re: { Barcelona JUG } Diseño de servicios

[Loïc Prieto]

Me suena que Spring resuelve el problema de no poder inyectar beans que sean de un ámbito más corto a uno más grande mediante proxis. El bean inyectado es realmente un proxi que recupera de forma transparente el objeto del ámbito apropiado. No sé si OSGI provee de algo similar, o si sería algo muy complicado de implementar. También está la posibilidad que menciona Jonathan de quitarle la naturaleza stateless al servicio. Aunque debo reconocer que no me termina de encajar porque eso crea problemas de escalado (si es que eso fuera una preocupación, vaya).

Realmente, cuanto más lo pienso, más apropiado veo simplemente pasar los argumentos a los métodos privados. Creo que es más escalable, si necesitamos en cada método privado los datos que proporcionan el Requestor. Otra opción es pasar a los métodos privados sólo los datos del Executor que necesitan (nombre, email, dirección, etc, según lo que procese ese método).

[Jonathan Vila Lopez]

chicos..... 

Bundle CORE = servicios, acceso a DB

Bundle WEB = web service, transformadores, acceso a los servicios

Los servicios ( singleton o no ) los inyecto en el bundle WEB

El tema esta en que es en el bundle WEB donde se genera la clase Requestor

Si el servicio es singleton me obliga a pasar la instancia Requestor a sus metodos publicos y por tanto propagar ese argumento a todos sus metodos privados que lo usen. Y ese diseño haria que todos los servicios acabaran teniendo 20 metodos TODOS con el argumento Requestor...... y no me acaba de gustar.

Si el servicio no es singleton puedo inyectarlo en la capa web y luego hacerle un set del objeto Requestor antes de llamar al metodo del servicio,  y en sus metodos usar el atributo privado Requestor.

Pero, lo que me gustaria es que el Servicio ( no siendo singleton ) se creara ya usando el constructor con el Requestor, pero eso ni idea de como hacerlo con la inyeccion ya que ese objeto Requestor se genera dinamicamente en cada peticion.

Jonathan Vila       jonath...@gmail.com