Modelo inusual: Núcleo de la composición contendor/contenido.

¡Saludos, ávidos reventadores de teclados!

Después de consultarlo con algunos krakens de la escena y ser guiado por ellos he decidido ponerme manos a la obra y darle al diseñador de diagramas para ilustrar lo que creo que me han contado. Y parece ser que el núcleo de la composición es esto.

ClassDiagram1

Aunque como mis facultades están a nivel de 2 de Agosto, tullido mentalmente y con hambre de bollos, puede que se me esté escapando la esencia de lo que me han contado (¡que soy muy torpe a veces!).

De esta manera podríamos tener el mismo elemento en varios contenedores, de manera que podríamos escribir el siguiente código:


        public void AddTwoRelationsForTheSameObject()
        {
            var element = new ComposableElement { Name = "Element1"};

            var rel1 = new Emplacement { Left = 0, Top = 0, Target = element };
            var rel2 = new Emplacement { Left = 20, Top = 10, Target = element };

            element.Contents.Add(rel1);
            element.Contents.Add(rel2);
        }

Como podéis ver, los elementos no poseen de forma intrínseca unas coordenadas, sino que la relación (Emplacement) es quien completa esos datos del modelo.

El problema que publiqué ayer podría empezar con algo así, ¿qué os parece? ¿Errado o fetén?

4 pensamientos en “Modelo inusual: Núcleo de la composición contendor/contenido.

  1. Hola Jose Manuel,

    Esa era la alternativa que te comenté al principio ( https://twitter.com/XaviPaper/status/362484328082571266 ) a excepción de q la relación era M:M y por tanto estaba mal la cardinalidad. De todas formas cuidado con 2 cosas que deberás controlar por reglas de negocio:
    – Una página no puede contener otra página
    – Un control no puede contener otro control

    Al simplificar tanto el model (que me parece una alternativa muy buena) hace que se te cuelen en el modelo cierta casuística que tendrás que controlar por código, pero la alternativa me parece buena para el problema que comentaste

  2. Hola Xavi. Muchas gracias por haber colaborado en el diseño. Pienso que es preferible tener un modelo ligeramente permisivo pero sencillo, aunque luego tenga que restringir ciertos comportamientos por medio de lo que sería una regla de negocio. Hacer un modelo que tuviera implícita esta restricción estructuralmente podría ser más costoso, en mi opinión. ¿Cómo lo ves/véis?
    No obstante, hay otra cosa que me preocupa, y es cómo representar los enlaces de datos. Por ejemplo, una etiqueta a la que se le pueda asociar el nombre de un cliente desde una fuente de datos. A lo mejor algo sencillo bastaría, como un contexto local + algún tipo de sistema de enrutado, como las Path de los Binding de .NET. Pero bueno, creo que esto daría para otro artículo más adelante🙂

    Seguiré indagando sobre el modelo que me proponéis tú y Juanma. La verdad es después de darle unas cuantas pensadas, cada vez me convencen más.
    ¡Un saludo!

    • Sip, a mi tb me parece la mejor alternativa, de todas formas no dudes en preguntar siempre q necesites una opinión, y si puedo ayudarte no dudes que lo haré…😉

      En cuanto al tema de los bindings depende de como tengas montado el resto del modelo, pero tener un string como lo hace XAML no parece una mala alternativa a nivel de modelo. De todas formas deberías de alguna forma validar q no te confundas en una letra, mayúscula, … Para ello te recomendaría usar algo tipo lambdas. Te muestro un ejemplo…

      control.AddBinding(x => x.Nombre)

      No sé si me explico…

      • Hola Xavi🙂 Buenos días! Muchas gracias por ofrecer tu ayuda. La verdad es que a veces se presentan unos retos que ni te esperas en los que te quedas totalmente desarmado y tienes 2 opciones: a) lo resuelvo a lo cutre y que funcione como sea. b) lo resuelvo bien.
        Realmente, para mí la “a” no es una opción y menos cuando lo que pretendo es aprender. He aprendido que hacerlo a lo fácil, sale difícil y te arrepientes más pronto que tarde.
        Respecto a los enlaces de datos, entiendo perfectamente lo que dices🙂 Es como un “tipado fuerte” para evitar fallos sintácticos y para permitir que la refactorización vaya bien en el caso de hacerla. ¡Es lo suyo! Aunque desde el punto de vista del modelo seguramente sea una cadena estilo ruta: “\root\usuarios\nombre” o “\root\usuarios\apellido”.
        No obstante, conforme avance, se irán presentando seguro problemas que ni me imagino, jajaja.

        A ver si hoy puedo echar unas horillas con el tema.
        Un saludo y buen fin de semana😀

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s