Preguntas de diseño

[Guillermo Colazo]

Hola,
Estoy trabajando en un proyecto nuevo con Katari y tengo las siguientes preguntas:
1) Quiero crear un  modulo (nombre: recomendados) que en la capa de presentación va a tener un slideshow(carrusel) que utiliza ajax.
Pregunta: cuál es el lugar correcto para ubicar los js correspondientes a ese carrusel?
a) En un módulo común como katari-ajax, donde se los tiene a todos los js. Este módulo sería una dependencia del módulo recomendados.
b) En el módulo style.
c) En el mismo módulo recomendados, donde quedaría 100% desacoplado de otros módulos.

2) En el caso de tener entidades de dominio + interfaces de dao + 2 implementaciones de esos daos,
Pregunta: cuál es el diseño que se debería seguir en katari para poder reutilizar correctamente las entidades e interfaces, sin quedar acoplados.
a) Crear un jar(no modulo de katari) con las entidades+interfaces de daos. Luego crear 2 módulos de katari donde se agrega como dependencia ese jar, y se implementa el dao.

Espero haber explicado bien, espero sus comentarios y otras opciones de como solucionar estos problemas ya que llevo solo 10 días con katari.
Saludos,
Guillermo

[Pablo Graña]

katari-ajax quedo como un modulo 'catch all' donde ponemos las
bibliotecas mas utilizadas. Por ahora solo esta yui, prototype y
fckeditor.

Si el carrusel es estandar y tiene sentido reutilizarlo, habria que
ver donde meterlo para que este disponible para otros usos. Pero la
mayoria de las veces el mejor lugar es el propio modulo
('recomendados'). En style suelo poner js relacionados con la
navegacion. Y tambien importo (en main.dec) js servidos por otros
modulos que se que se van a usar en toda la aplicacion. Asi que en
principio, seria la 'c'.

Con respecto a los DAO, lo mejor es no tener multiples
implementaciones. Calculo que debe ser porque tenes una version que
usa hsqldb y otra que usa mysql. Si tenes opcion, trata de dejarle los
temas de portabilidad a hibernate.

Si necesitas lo de las interfases, plantea el problema en relacion al deploy:

- Version c/ hsqldb.
- Version c/ mysql.

Lo que podes hacer ahi es:

recomendados: tiene ui, command, entities y las interfases de los DAO.
Aca vas a tener que poner mocks de los DAOs p/ poder probar.
recomendados-mysl: depende de 'recomendados' e implementa las
interfases de los DAO p/ mysql.
recomendados-hsqldb: depende de 'recomendados' e implementa las
interfases de los DAO p/ hsqldb.

Despues tenes que armar los wars:

<app>-mysql: depende de recomendados y recomendados-myql. Configura
las implementaciones de los DAO p/ mysql.
<app>-hsqldb: depende de recomendados y recomendados-hsqldb. Configura
las implementaciones de los DAO p/ hsqldb.

Por supuesto, este planteo esta asumiendo un monton de cosas, asi que
fijate bien si te sirve.

saludos

2011/8/16 Guillermo Colazo <guillerm...@globant.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "katari-user" group.
> To post to this group, send email to katar...@googlegroups.com.
> To unsubscribe from this group, send email to
> katari-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/katari-user?hl=en.
>

--
Pablo Gra\~na
Chief Architect
Globant
Arg Office: +54 (11) 4109 1743
UK  Office: +44 (20) 7043 8269 int 8043
US  Office: +1 (212) 400 7686 int 8043

[Guillermo Colazo]

Ante todo muchas gracias por las respuestas.
Las implementaciones de los DAOs son porque una va a una base de datos y la otra a un servicio rest.
Básicamente uno es un módulo online(rest) y otro offline(db).
Teniendo esta escenario, tambien sería adecuado tener todo en el mismo módulo y a la hora de armar los WARs configurar cual implementación?
Desde ya muchas gracias.
Saludos,
Guillermo.-

[Juan Pedro Pereyra]

Agrego una cosa a lo que dijo Pablo, aunque sin entrar en mucho detalle, Katari usa el concepto de Repository (objeto de dominio) en lugar del DAO (objeto de capa de acceso a datos).

Te dejo un link que habla al respecto http://domaindrivendesign.org/node/123

--Juan

2011/8/16 Pablo Graña <pablo...@globant.com>

[Pablo Graña]

Ah, ok, si, vas a tener que tener varias implementaciones.

Pero ademas tenes otro problema muchisimo mas complicado: la semantica
tipica de un ORM (ej: hibernate o jpa) es muy diferente a la de un
servicio. Vas a tener que pensar muy bien tu interfase para que tu
interfase no tenga 'leaks' de esa diferencia de semantica. El punto
concreto es el tema del lazy. Tal vez tengas que modelar tus DAOs (o
repos) guiandote por el api del servicio.

Otro tema: nosotros favorecemos los conceptos de Domain Driven Design,
y sus convenciones. Te lo comento porque haces mencion de DAO (data
access objects), cuyo objetivo es abstraer el acceso a datos. En
Domain Driven Design, Evans plantea otro concepto bastante parecido a
DAO: el repositorio. La diferencia fundamental es que el repositorio
forma parte del dominio y sirve para acceder a los roots de los
aggregates.

[Martin Olivera]

Gracias por las respuestas, tenemos varios casos de reuso o similares con Guillermo y otro nproyecto (tenemos 3 proyectos en simultaneo con funcionalidades compartidas en parte) para educ.ar y estamos viendo como aprovechar el potencial de Katari.

respecto a los Repository en nuestro proyecto creamos un modulo para offline, con su repository q usa Hibernate contra DB local, mientras que hicimos otro modulo online con un Repository para online que se encarga de la API REST. Lo cierfto es que no se parecen demasiado, pero pienso que estaria bueno al menos abstraer en un interface por ej

Lo que si usamos en comun son objetos de dominio, que estan en otro modulo "importador" que es el que llena la base local a partir de archivos ZIP. No me parece que nos esté quedando demasiado ordenado asi, con los objetos de dominio en un modulo, y dos respositorios "verticales" para offline y online que usan los mismos domain. Ademas tengo muchas dudas sobre la granularidad de los modulos, por ejemplo en apliaciones "Katari- best - practices" tengo tanto modulos como User Stories, se puede estimar un factor entre numero de User Storie y numero de modulos p /implementarlo, para mas o menos ver si estamos bien?

El modulo de "recomendados" que esta armando Guillermo lo vamos a usar en otros dos proyectos, pero es un modulo muy "angostito", digamos que su interfaz es a lo sumo un div con data y js del carrousel accesible por AJAXA, que otros proyectos vamos a invocar por AJAX y decorar cada uno a su manera...

estamos po el camino correcto? para cada cosa compartida hariamos un modulo? o mejor un modulo tipo "compartidos" y juntar a hi todo?

En el escenario este, mas complejo que les comento, que pasa con os repositorios? tenbemos 3 proyectos independientes que van a usar la misma API REST, los 3 hechos con Katari, no hay forma de compartir eso? por ahoa estamos copiando y pegando codigo, y la API queda bastante "desparramada", pero encima ni siquiera el codigo nos va a quedar unificado, en caso q cambie la API (digamos que agreguen o saquen un parametro) vamos a tener que tocar Repositories en los 3 proyectos. Como se puede compatrir eso pensando en Katari?

El 16 de agosto de 2011 09:55, Pablo Graña <pablo...@globant.com> escribió:

[Pablo Graña]

Hay que pensarlo mucho mejor, pero es fundamental no duplicar codigo.

El primer paso para decidir los modulos es tener el modelo de dominio.
La division en modulos en esta etapa se basa 100% en conceptos de
dominio. El criterio es complejo, y Evans lo explica muy bien: 'si el
dominio cuenta una historia, los modulos son los capitulos'. Lo que
planteamos con katari es que, en primera instancia, todas las capas
van junto con los modulos de dominio.

Despues tenes el tema tecnico: el foco aca es como no duplicar codigo.
Este suele ser mucho mas facil: si se necesita en 2 lugares, ponerlo
en un jar aparte.

Por el lado del tama\~no de un modulo, no hay una metrica general. La
guia siempre es cohesion y acoplamiento. A veces puede aparecer 1
clase sola en el dominio, a veces son 10 o 15. No hay que pensar en un
modulo como una user story o un use case.

Una cosa que se suele hacer y no me gusta para nada: sacar una o dos
clases de 1 modulo porque otro modulo depende de esa o esas clases. Si
el modulo es cohesivo, no es mala idea depender de todo el modulo, por
mas que solo se importen 2 clases.

saludos

2011/8/16 Martin Olivera <martin....@globant.com>: