Entrega#2 - Grupo 9

Observaciones Técnicas:

• • No hay tag en el SVN

  • Sin cambios no corren los tests de persistencia y no hay un TXT que indique los cambios que hay que hacer (Copiar base de datos en C:\SQL)

  • Los tests deberían tener la siguiente estructura, para evitar que el fallo de un test evite que fallen los demás.

try {

// abro sesión

// trabajo

} finally {

// cierro sesión

}

• • No hay un test para el requerimiento "Consultar todos los grupos de un Usuario" aunque la funcionalidad está implementada.

  • No hay un test para el requerimiento "Obtener los comentarios agregados por un usuario" aunque la funcionalidad está implementada.

  • Sugerencia: Podrían haber utilizado Stylecop para estandarizar el código.

Mapping

• • Considerar mapeo con Annotations por sobre XML.

  • En el mapeo de Comentario no correspondería un cascade=all. Es decir, desde un punto de vista conceptual, no parece que tendría sentido que todos las cambios (delete, select, merge) a darse en la entidad Comentario deberían propagarse a los usuarios.

  • Pensemos, por ejemplo, en la posibilidad de eliminar un comentario (session.delete(comentario)). Esto traería acarreada una eliminación del registro correspondiente al usuario. En el caso de foto, como bien aparece en los mapeos, tiene sentido que al eliminarse una foto se propague la eliminación a los comentarios asociados, ya que el ciclo de vida de los comentarios está más atado al de la foto. Lo mismo ocurre con los grupos y su asociación con usuarios (Grupos_Usuario).

  • No queda clara la decisión de por qué mapear, por ejemplo, la relación one-to-many desde Foto a Comentarios y no hacer lo mismo hacia las etiquetas. Por un lado daría la impresión de que no desean que los extemos (foto y usuario) de la relación puedan acceder a las etiquetas desde su colección, y manejar la persistencia de las mismas desde la tabla intermedia únicamente. Por otro, ambas entidades poseen métodos para manejar colecciones de etiquetas, lo que haría suponer que esta información de mapeo fue omitida tanto en el Foto.hbm.xml, como en el Usuario.hbm.xml.

  • En Mensaje ocurre algo similar con la entidad Usuario. De la forma en que está mapeada la relación no puede esperarse que al traer un mensaje de la BD, ésta traiga al usuario cargado en el atributo "emisor" de la clase Mensaje. A su vez, si se construye un mensaje desde el constructor de 3 parámetros proporcionado, y no se asocia antes o luego el mensaje a la colección de la entidad "usuario" y se persiste esta también, la relación entre usuario y mensaje no quedaría plasmada en la BD.

  • En resumen, lo anterior indica que cuando en una entidad tenemos una referencia a otra, hay que emplear un criterio equivalente en los mapeos. Si mi decisión fue no mapear un extremo de una relación (ej. no quiero navegar desde mensaje a usuario), porque consideré que, por las características de mi negocio, la navegación en esa dirección no sería necesaria, el hecho de contar con referencias a dicha entidad en la clase origen, no plasmadas en los mapeos, puede generar inconsistencias o resultados no esperados al dialogar con Hibernate.

  • No se ve en ninguna relación el concepto de laziness. No queda claro si es una decisión basada en el comportamiento que provee NHibernate por default, o si omitieron este aspecto.