Otra de ViewModels (con Cinch)

Señores, la peña está aburrida de escucharme insistir en cosas como SOLID, DDD, Separation Of Concerns, MVVM, XAML y demás.

Pero copón bendito, ¡si es que llevo razón! Dejad de hacer ñapas y programad como hombres, ¡joder!

Pues después de este arrebato para aquellos que más que programan “tirar líneas” y no aspiran a hacerlo mejor, os digo: el modelo es el camino , la verdad y la vida..

Para ello os propongo el siguiente caso extravagante. Queremos construir una instancia de nuestro modelo mediante un “asistente”. La interfaz da una serie de opciones para controlar sus propiedades. Hasta aquí todo es normal, pero ahora llega lo novedoso: nuestro modelo es un control visual. ¡Imaginad un botón! Queremos establecer sus propiedades con el asistente y el usuario puede ir controlando, por ejemplo, el tamaño del borde, el color de fondo, su texto…

Bien, nosotros queremos que cuando el usuario vaya introduciendo modificaciones en el control, se vaya actualizando su apariencia.

La cosa seguramente más de alguno todo esto lo haría a base de eventos y “sin complicarse” la vida, pero si quieres ser un maestro de la abstracción puedes optar por hacerlo como yo, un dopao de MVVM con 0% de materia grasa.

¿Qué he hecho? He creado la ventanita y un ViewModel que se hacer cargo de todas las propiedades del modelo (un Botón hecho a medida). Pero ahora viene lo divertido. Como no me gusta andar descalzo, voy armado con el Framework MVVM del maestro Sacha Barber, un tipo prático donde los haya, pero con un gusto por la elegancia y por la pureza.

Ese peaso de framework tiene durezas a chorros, pero una de las que más encandilan son las relacionadas con las validaciones. Te recomiendo que te pongas a mirarte Cinch si quieres hacer algo decente con MVVM y que prestes atención a los DataWrappers.

Básicamente un DataWrapper (envoltorio de datos) es eso, un envoltorio que se ocupa de encapsular una propiedad del ViewModel y proporcionarle soporte para validación y/o edición.

El tema es que esos DataWrappers contienen un DataValue con el dato encapsulado. Es posible agregar reglas al DataWrapper para que el ViewModel padre se entere de si se encuentran en un estado válido o no. La vista reaccionara a las validaciones sin tener que realizar actualizaciones. Todo perfectamente controlado y muy declarativo.

Bueno, para enteraros del tema no hay nada mejor que los tutoriales que pone Sacha en The Code Project. Por ejemplo: http://www.codeproject.com/Articles/38672/WPF-If-Carlsberg-did-MVVM-Frameworks-Part-4-of-n

¿Y para qué quiero Cinch y los DataWrappers del demonio?

Pues la verdad es que es muy jodido de explicar, pero en esencia resulta que el usuario puede meter cualquier dato y puede que ese dato no sea correcto. Imaginad el borde del botón. Le ponemos 1.000.000 de píxeles de ancho y la previsualización, evidentemente, pegaría un flete enorme al renderizar semejante barbarie.

La idea es que cuando el dato no sea válido, la previsualización PASA OLÍMPICAMENTE del dato.

¿Cómo? Con disparadores en el XAML, concretamente un estilo con DataTriggers 😉

Y ahora, para quien quiera saber la solución final, aquí está la pregunta que hice en Stack Overflow al respecto, que detalla todo el lío en inglés, que incluye la solución, con un trocete de XAML por si queda alguna duda.

http://stackoverflow.com/questions/17675285/mvvm-make-binding-update-viewmodel-only-when-data-is-valid/17695186?noredirect=1#17695186

Finalmente, si has llegado a leer hasta aquí y no te ha dado una embolia cerebral, o no te has dormido de aburrimiento, o si aún no piensas que se me va muchísimo la olla, quiero felicitarte sinceramente. ¡OLÉ TUS HUEVOS!

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!

Translator Pattern. Know Your Patterns :)

 

image

 

This pattern is really simple. It provides a method to convert from a representation to another. The same concept can be represented in many ways. Sometimes you have to “import” and “export” representations, so you have to provide a proper encapsulation for the logic that converts from one object to another.

Why would you need to do that? In my personal experience I have used it to convert instances of “legacy” clases that are not too well designed. It happens that a lot of logic already exists in the solution that work with those clases, so redefining them would be really expensive. The brand new features use better an more robust clases. For newer parts, I use a translator to perform a one time time conversion. When a legacy part of the application needs a “new” instance, I request a conversion to the old class instance.

It can be seen as a pattern similar to Adapter or Builder. But Adapter translates interfaces and provide a “wrapper” that interacts between the outer world and the wrapped classes along all its lifecycle. Builder creates complex objects. It’s a similar pattern, but I don’t feel it’s the same as the builder doesn’t translate, it builds up an instance.

What do you think about it? Do you see a Builder here? Smile

Differences between Abstract Factory / Builder / Adapter

When it comes to patterns, it’s important to know the differences. Sometimes you have to name a class and you tend to call it “a X-builder”, or a “X-Generator”. But… are you sure you gave it the correct name?

It’s important to name things properly in our projects. From variables, to methods and classes. It REALLY matters. Even more when you are part of a team. When we are implementing a pattern we should give every entity the right now to avoid ambiguity.

In this particular case, those patterns may seem to do similar things, but they don’t. So, how to identify each one?

image

I hope somebody is kind enough to point out the differences between them. Come on, participate! Comments are welcome.

Duck Typing FTW

Para que no se te olvide, golferas, si quieres programar como Dios manda deberías hacerlo siempre intentando programar “contra” interfaces, aunque no es una expresión que me guste mucho eso de “contra”, pero así todo el mundo lo entiende.

Para facilitarnos la tarea existe una técnica llamada Duck Typing.

“Si anda como un pato, nada como un pato y vuela como un pato, entonces es un pato”.

En pocas palabras Duck Typing es conseguir tratar como un objeto fuese algo que realmente no lo es, aunque cumple con sus requisitos. Esto se traduce a tener tener un tipo que no implementa cierta interfaz, pero lo tratamos como si la implementase.

El gran Juan María Hernández (@gulnor) publica en su blog publica un artículo especialmente interesante donde explica muy bien qué es y cómo funciona, además de exponer una pequeña implementación de andar por casa ayudarnos a entender cómo funciona por dentro.

¿Cómo lo consigue? Con reflexión, invocando atributos y métodos como si realmente estuviésemos trabajando con el tipo que queremos.

Sin duda, un concepto revolucionario con lo que podemos crear código más abstracto  y menos acoplado, que es de lo que se trata.

Por cierto, si no quieres devanarte la sesera para hacerte tu propia implementación de esta , échale un vistazo al DynamicProxy o al aparentemente bueno ImpromptuInterface (http://code.google.com/p/impromptu-interface/).

Venga, a probarlo ya, ¡jodebles!