Data Transfer Objects in Domain-Driven Design Patterns

Data Transfer Object. A simple pattern for exchanging information between the Presentation Layer and the Service Layer.

The basics are explained in lots of articles all over the web, but there are some details that are not so obvious. I implemented DTOs following my instincts, but I always had the feeling I was asuming things and not doing it well.

That’s whay I keep on asking about the insights of patterns like this.

I found a very interesting article about DTOs by Bozhidar. I recommend you to read it because it gives several hints and advices on how to use this pattern sucessfully.

Bozho’s tech blog – On DTOs

The last part I want to notice is the question I posted. As you see, Bozher was really kind and answered really quick.

Thanks!

Recurso estático en XAML a partir de un Singleton

No he encontrado manera mejor de hacerlo que esta:

<x:Static Member="common:ResourcesUIService.Instance" x:Key="ResourcesUIService"  />

Con esta sencilla nomenclatura y si has diseñado bien tu singleton, la extensión Static lo dará todísimo y tendrás acceso desde tu XAML favorito a la instancia con cosas tales como Bindings (que es de lo que se trata, ¡jojojo!).

Ponlo a prueba y nota su aroma.

Reto Fuerte y Duro

En estos días se me ha ido mucho la olla al ver cómo a diario se me presentan situaciones que, si fuera un kootre, resolvería rápida y fácilmente.

Me pregunto si no hay una manera mucho mejor y más sencilla de hacerlo.

Básicamente lo que quiero hacer un es diseñador de FlowDocuments con algo parecido a los Bindings pero sin ser un FlowDocument. Me explico: Si cogemos un FlowDocument y le metemos cosas, vamos a tener eso, un FlowDocument.

Lo que quiero es un modelo más abstracto que no esté atado a WPF. Hacer lo que hace WPF sin WPF es un jodido caos.

Ejemplo. Tenemos un documento vacío y queremos añadir un párrafo. Haciéndolo desde el código es más sencillo que el mear. Pongo un FlowDocument y le meto un Paragraph.

¡Pero no queremos eso! Caca.

Queremos representar nuestro modelo de negocio, que en este caso son elementos que se representará gráficamente. O sea, el modelo es la propia UI, o algo que se le parece mucho. En realidad se trataría de un modelo que casi se confundiría con las clases de WPF. El tema está en que sea, además, diseñable.

¿Qué me decís?

¿Es un temita, eh? Pues tengo unas ganas locas de saber cómo podría abordarse con altas probabilidades de éxito. El mundo de los diseñadores es bastante jodido y prueba de ello es que algunos de los más grandes programadores se dedican a ello, como Unni Ravindranathan o Harikrishna Menon.

Bueno, ahí lo dejo, por si algún ávido Master se digna a proponer soluciones.

¡Talueg!

Software con bajo acoplamiento y máxima cohesión

¿Hay algo más bello que un programa hecho con bajo acomplamiento y máxima cohesión?

Aparte de estar bien diseñado, cumpliendo tan solo estos 2 requisitios, la calidad del software aumenta MUCHÍSIMO, por lo tanto mi consejo es que, por favor, ¡una clase/método nunca debería saber más de lo necesario!

Algo tan sencillo habitualmente es pasado por el forro de los cojones.

Aplanar propiedades de dependencia

Muy útil para evitar tener propiedades redundantes cuando hay herencia (recuerda que las propiedades de dependencia pueden ser heredables). Here I go with the explanation!

Problema:

  1. Tenemos una estructura en árbol de padres e hijos, todos ellos DependencyObjects.
  2. Tenemos una propiedad de dependencia heredable
  • Queremos que el valor de la propiedad de dependencia más repetido en los hijos pase a ser el valor del padre.
  • A partir de ese momento, la propiedad en el padre es el valor más repetido en sus hijos.

¿Qué podemos hacer ahora?

Puesto que por el mecanismo de herencia, el valor del padre se hereda en los hijos, lo ideal sería que si el padre tiene el valor más repetido, en todos los hijos que tengan el valor más repetido se “reseteara” la propiedad. Haciendo esto, efectivamente, el hijo hereda el valor del padre automáticamente, que además será el valor óptimo (el más repetido). Además, esto es recursivo, por lo que el padre de todos los padres tendrá los valores más comunes dentro de sus hijos.

Esto puede ser útil en varias ocasiones (a mí ya me ha sido útil Winking smile)

Aquí dejo el código:

 private static void FlattenProperty(IParentOfDependencyObjectChildren parent,
            DependencyProperty dependencyProperty)
        {
            var childrenList = parent.Children.ToList();

            if (childrenList.Any())
            {
                foreach (IParentOfDependencyObjectChildren child in childrenList)
                {
                    FlattenProperty(child, dependencyProperty);
                }

                var values = childrenList.Select(o => o.GetValue(dependencyProperty)).ToList();
                var mostRepeated = values.GetMostRepeatedItem();
                foreach (var child in childrenList)
                {
                    if (child.GetValue(dependencyProperty).Equals(mostRepeated))
                    {
                        child.ClearValue(dependencyProperty);
                    }
                }
                parent.SetValue(dependencyProperty, mostRepeated);
            }
        }
 public static class EnumerableExtensions
    {
        public static T GetMostRepeatedItem<T>(this IEnumerable<T> list)
        {
            // group by value and count frequency
            var query = from i in list
                        group i by i into g
                        select new { g.Key, Count = g.Count() };



            // compute the maximum frequency
            var ordenada = (from c in query orderby c.Count descending select c);

            return ordenada.First().Key;
        }
    }
    public interface IParentOfDependencyObjectChildren
    {
        IEnumerable<DependencyObject> Children { get; }
        void SetValue(DependencyProperty dependencyProperty, object value);
    }

Aberración Máxima

Estaba buscando ejemplos por Internet y me lo he encontrado: El súmmum.

Parafraseando el famoso traje biónico de Crysis os presento la antítesis del código limpio.

Os reto a que encontréis algo peor. Un método Get que no devuelve nada y que encima ¡establece cosas! Chorricode destilado.

		/*Cálculo de la X2*/
        private void CalculateX2(Graphic base)
        {
            if (base is Numeric)
                ((Numeric)base).getColumns(((Field)base).Cols);
            else if (base is Text)
                ((Text)base).setWidthInix2();
        }

¿Sospechoso eso de ver un getColumns(…) cuyo valor no se almacena en ningún sitio?

¡Es que es es un método void!

        public void getColumns(int s)
        {
            _getColumns(s);
        }

“int s”, ¿estamos locos? Y eso del guión bajo da un mal rollo que no veas. Además de quedar horrible a la vista :S

        private void _getColumns(int s)
        {
            this.width = (this.averageWidth) * s;
            this.Initialx2 = Initialx1 + this.width;
        }

Meaninful names, sí señor. Un getter que es un setter encubierto.

image

Herencia en Dependency Properties

El temita jodido del otro día, cuando estuve dándole caña a las propiedades de dependencia heredables (FrameworkPropertyMetadata.Inherits)

Yo tenía una magggnífica propiedad llamada Relleno compuesta de:

  • Color (Color)
  • Id de patrón (int)
  • Tint (double)

Esta propiedad se hereda por por lo que los elementos del árbol visual. Hasta ahí, bien.

El asunto se puso marrón oscuro cuando en un hijo me daba por modificar el miembro “Color”. ¿Qué ocurría?

Resultado esperado:

image

Resultado obtenido:

image

La razón es que el Relleno es una instancia compartida entre todos los elementos de la jerarquía. El del padre es la misma instancia que el del hijo, por lo que si modificamos el Color al Relleno, efectivamente, ¡estamos cambiando la misma cosa!

¿Qué hemos de hacer? Pues la cosa quizá no es muy sencilla, pero lo primero de todo es que tenemos que tener claro qué es un Value-Object, es decir, cuándo el valor de una cosa determina qué cosa es.

Esto depende de la semántica que queramos darle. Para mí, si tengo una instancia de Relleno y le cambio el Color, serán dos patrones distintos, por lo que no sería admisible cambiar el Color, sino que debería otra crearme otra instancia de Relleno distinta (Relleno debería ser inmutable). De estas manera, 2 instancias distintas nos darían el resultado deseado.

Espero que la monserga te haya servido, pequeño saltamontes.

Hala, a echarte un Call Of Duty, que ya es escrito bastante, mamoncete.