Herramientas

Asociación uno-a-muchos

La asociación uno-a-muchos suele ser complementaria a una asociación de muchos-a-uno.

Los expertos en Java suelen recomendar implementarlo de una manera bidireccional y no unidireccional, por el mal rendimiento que provocan.

Si lo implementamos de manera unidireccional, por ejemplo, si queremos asociar productos y categoría, y sabemos que una categoría está formada por muchos productos y solamente hacemos las asociaciones de categoría, esto nos generaría tres tablas, la tabla de productos, la tabla de categorías y una tabla join.

Sin embargo, si la implementamos bidireccionalmente, podríamos tener las dos asociaciones tan solo con tener una clave externa que nos llevase desde producto a la categoría a la cual pertenece.

Por eso, en cuestión de rendimiento y de la cantidad de sentencias que genera el ORM, lo ideal es que es que sea bidireccional.

A nivel visual

A nivel visual suele haber dificultad a la hora de diseñarlo, ya que, sobre todo los principiantes suelen tender a diseñar el lado opuesto, es decir, a diseñar el muchos-a-uno.

Esto ocurre porque es bastante más fácil hacerlo de esa forma, ya que normalmente con un desplegable, si por ejemplo estamos dando de alta un producto, con un desplegable con las categorías lo tenemos resuelto.

En ocasiones nos puede venir bien esta opción, sin embargo, en otras ocasiones queremos tener alguna alternativa porque nuestra lógica de negocio o la experiencia de usuario la queremos hacer de manera que el usuario, en una misma pantalla, rellene los datos del lado uno y también dado muchos.

Alternativas para uno-a-muchos

Si el lado muchos no tiene una gran cantidad de elementos y estos, además, ya están creados, podemos utilizar una lista de botones de input de tipo check.

Un ejemplo de este caso sería cuando en cualquier plataforma podemos indicar en nuestro currículum las tecnologías que conocemos, y cada una de ellas son una entidad de otro lado. Hacemos una asociación y así podemos marcar más de una mediante esta lista de checks.

También lo podríamos hacer a partir de una lista de botones toggle de una manera sencilla. Cualquiera de los frameworks que podemos utilizar en nivel visual, como por ejemplo Bootstrap, nos ofrecen componentes para poderlo hacer.

De esta forma hacemos la lista más atractiva, con una serie de botones que si pinchamos sobre ellos se quedan marcados, y así el usuario podrá elegir más de una opción.

También podemos implementar algún tipo de drag&drop múltiple, en el que podríamos pinchar, arrastrar y soltar en una determinada área aquellos elementos con los cuales nos podemos asociar.

Con este efecto, seguramente conseguiríamos que la experiencia de usuario sea algo más atractiva a la hora de rellenar el formulario.

Si la lista de elementos es muy larga o queremos poder crear nuevos elementos desde del formulario, nos encontramos con el concepto de subformulario, que realmente no es nuevo y puede sonar a quién haya trabajado con bases de datos en Access, por ejemplo.

Aquí tenemos un ejemplo de la documentación oficial de Thymeleaf, en el que se nos presenta este concepto, que no es más que un formulario dentro de otro.

Vamos a dar de alta una entidad, en este caso un semillero, y podemos asociarle diferentes filas, como si tuviéramos en ese semillero distintos contenedores.

Este formulario incluye dentro el subformulario filas, de manera que cuando vamos pulsando sobre el botón “Añadir fila” se nos van añadiendo dinámicamente campos que podemos ir rellenando.

Cuando pulsemos el botón “Añadir semillero” se enviarían todos esos campos que se han añadido y cumplimentado.

Además de poder implementarlo para que cada vez que se pulse el botón se añadan filas a una tabla, se pueden añadir a un panel que podríamos estructurar con algo más de diseño, o podríamos utilizar diferentes paneles que se fueran anidando en función de la cantidad de campos que tenemos.

Incluso, si el formulario que tenemos nos lo permitiera, podríamos hacer alguna combinación con elementos de los que hemos visto antes, sobre todo de lo más visual y lo más lo más llamativo.

Esto es adecuado para un número de campos en el subformulario que no sea muy grande, porque si vamos a crear una tabla que sea muy grande y con un ancho a toda la pantalla y con 10 campos, esto se vuelve farragoso, sobre todo si los campos son largos y son algo complicados.

En ese caso, si el número de campos es más grande, lo que podríamos hacer es tener una tabla o un panel dónde se mostraran los campos esenciales una vez los hayamos rellenado, pero podríamos abrir el subformulario a través de un modal.

De esta manera, este subformulario modal se pondría encima de nuestro formulario, lo podríamos cargar de bastantes más campos, lo podríamos rellenar y cuando lo enviemos se nos actualizaría la tabla de detrás.

Podríamos añadir también la alternativa de editarlo en ese momento y que volverá a salir del modal, y de esa manera pues no habremos agobiado al usuario con una gran cantidad de campos directamente en la misma pantalla, lo osa que puede hacer que la experiencia de usuario de nuestro formulario pues sea negativa y eche para atrás al usuario a la hora de rellenarlo.