Espacio de Dario Quintana

Un nuevo Application Block nació: Policy Injection Application Block.

Al parecer, con este nuevo App Block podremos aplicar conceptos como el de SoC (Separation of concerns) en nuestra aplicación, tal como lo venían predicando de manera similar frameworks como Spring.Net.

Para ser claro, podriamos hacer que en un objeto de nuestra aplicación, al ejecutarse un método, realice una entrada al archivo de log, de forma transparente en el código cliente. 

Esto se pone más interesante, en la interoperabilidad que podremos llegar a tener con otros App Blocks, como ser: Validation, Logging, Exception entre otros.

La idea básica es trabajar con una factoría de clases, para la instanciación de nuestros objetos. Dicha factoria inspeccionará la configuración, para ver si el objeto posee politicas que aplicar, si no las posee, se crea una instancia común y corriente, si las posee, se crea un proxy para que el framework pueda manejar al objeto de forma transparente al cliente.

Escenario donde podriamos aplicar:

En nuestra aplicación un objeto que posee un método Guardar(Cliente obj). Utilizando estos conceptos, podríamos hacer que cada vez que se llame a este método, es decir, que querramos guardar un cliente, por medio del Policy Injection App Block se realize la validación del objeto (utilizando el Validation App Block), y si no es una entidad válida, dicho método Guardar no se ejecute.

Para más lean estos posts:

• Announcing the Policy Injection Application Block
• Policy Injection App Block - Behind the Scenes

Que buena pregunta: progamo bien? o solamente abro la IDE y comienzo a tirar lineas sueltas?

Bueno, está muy bien que al comenzar un proyecto comencemos a tirar lineas sueltas que vislumbran buenas ideas y quizas no estén muy bien organizadas, pero… en algún momento tendremos que aplicar a nuestro código la buena palabra: refactoring!

Un programador con unas cuantas lineas de código encima, deberia darse cuenta sobre cómo huele su código. Si aún no desarrolló el olfato es hora de que lo haga, a menos quiera asegurarse trabajo de por vida…creando código que no es mantenible (y bueno…hay gente que le gusta estar ocupada )

Aquí le dejo un post donde hay olores que le serán muy conocidos…otros no tanto quizas.

Y … si insisten en crear código IN,DES,NO, ó NULL-mantenible … sigan este enlace.

Así se titula el artículo en la revista .code que escribieron mi querido amigo Alan Lavintman y Germán Viscuso, -gente buena y muy activa en la comunidad hispana de db4o.

Aqui les dejo el articulo en pdf.

Reflector 5.0 está para descargar y movió su lista de plugins a Codeplex.

Y esta es una muy interesante feature:

LINQ and .NET Framework 3.5: Reflector supports query expressions and other concepts introduced in C# 3.5. To enable this feature select “.NET 3.5″ under View, Options, Disassembler, Optimization.

Con más razón, si estamos trabajando con una aplicación de acceso remoto, la validación de formularios es algo que debe hacerce, hoy día no alcanza solamente con validar el negocio.

Y los muchachos de patterns and practices, con el Validation App Block, parece que lo lograron, hechenle un vistazo a este post.

Que buena pregunta y me gustaría escuchar cómo validan ustedes su negocio. 

Validar el negocio no es para menos un tema trivial. A que llamamos validar el negocio? Bien cuando digo validar el negocio, estoy refiriendome a que debemos asegurarnos que estamos trabajando con instancias válidas de nuestras clases del modelo de dominio, es decir que nuestros objetos tengan un estado válido con el que se pueda trabajar. Y a qué me refiero con trabajar? Trabajar con el objeto seria intentar persistirlo, Ã³ enviarlo a otro ambiente por medio de serialización binaria, o también podria ser el caso en el uso de ambientes compartidos de objetos.

Citemos un ejemplo, donde tenemos la entidad Venta, que tiene campos como ser FechaEmision, NroVenta, Total, SubTotal, TotalImpuestos,Notas.

Podríamos validar este objeto de varias maneras: la popular y de la cual no soy partidario, es hacerlo de forma procedural e ir preguntado propiedad a propiedad si es válida cada una. Este enfoque se empieza a complicar si por cada propiedad tengo varias reglas a cumplir, por ejemplo:

• Tiene que ser mayor a 0 (cero)
• Tiene que ser menor a 50.
• La suma de X y de Y tiene que dar igual a él.
• Debe ser igual que una propiedad de otro objeto, de una clase diferente.

Ahora bien, se imaginan la cantidad de sentencias If solamente para la validación de una propiedad de un objeto.

Una opción más automatizada, es pensar que cada regla es un método, que acepta parámetros para la validación, y que luego, configuramos a que un objeto sea validado por un cierto numero de reglas. Y Cuando deseamos validar un objeto hacemos:

bool resultado = Validator.CheckAll(myOrden);

Lo que sucederia es que CheckAll iría checkeando regla a regla si se cumple, obteniendo el resultado acerca de la validez del objeto. Asi también podremos obtener un detalle sobre cuales reglas se han roto y cuales no.

Este enfoque es al cual le tengo más confianza y es el que profesan frameworks como CSLA.Net de Rockford Lothka, ya maduro y utilizado en diferentes ambientes de producción.

Ahora también el Enterprise Library viene con su framework de Validación para usarlo en el negocio: Validation Enterprise Library.

Ahora, si se dan cuenta, con este enfoque, una vez escritas las reglas, no necesitamos volver a escribirlas, solamente las aplicamos a quienes queremos.

Ahora bien, dicho esto…como lo hacen uds ?

Si quieren probar aplicaciones, el Virtual Appliance Marketplace es el lugar y hay para todos los gustos, desde los developers hasta para los gamers:

Subversion and WebSVN on Ubuntu Server: Es un servidor de Subversion ya preconfigurado, para poder realizar control de versiones de nuestros desarrollos, y lo más interesante, sin la dificultad del deploy.

Battlefield 2 Server: Y por el otro lado, si queremos levantar un servidor de Battlefield 2, estos muchachos ya lo hicieron y lo inmortalizaron.

Analizando la función IsNumeric de VB.Net, me encontré con algo interesante para contar. Los Try - Catch se deben ocupar en situaciones inesperadas, o eso es lo que me enseñaron.

Aquí les pego la función IsNumeric que millones de veces la habrá utilizado alguién que programó en VB alguna vez. Si la quieren mirar está en la clase Microsoft.VisualBasic.CompilerServices.Versioned.

         case TypeCode.String:
                  {
                        double num1;
                        string text1 = convertible1.ToString(null);
                        try
                        {
                              long num2;
                              if (Utils.IsHexOrOctValue(text1, ref num2))
                              {
                                    return true;
                              }
                        }
                        catch (FormatException)
                        {
                              return false;
                        }
                        return Conversions.TryParseDouble(text1, ref num1);
                  }

Explico un poco, si el resultado de la función es true, es Numérico, sino, no lo es.

Tomando como premisa de que solamente se pone Try-Catch en situaciones inesperadas…arribo a la conclusión de que el muchacho/a puede haber estado en una de estas opciones:

1) El que programó IsNumeric, no confia en su compañero que escribió IsHexOrOctValue o no confiá en si mismo que es peor. Hasta un goto aparece en IsHexOrOctValue.

2) Con ciertas cadenas IsHexOrOctValue genera excepciones…serán malas palabras ?

3) Es un tipo muy precavido. Algo tan tonto si llegase a generar una excepción, puede incomodar al programador.

4) Se olvidó de sacarle el Try-Catch: “ups…my mistake”

5) Quien va a mirar mi código ? !

6) Realmente no es tanta la sobrecarga que generan los Try-Catch, es decir, esto no le va a ser mal a nadie.

7) No tenía ni idea de la sobrecarga de los Try-Catch.

8 ) Ninguna de las anteriores…se le antojó un Try-Catch y punto!

9) Está super justificado el Try-Catch.

Conclusión:

Este post no es para críticar al hombre que escribió el IsNumeric, sino que viendo este trozo de código me puse a pensar de que muchas veces ponemos Try-Catch justificando con: “es por las dudas, mirá si pasa algo!”, y realmente no se justifica el costo de sobrecarga en el sistema, por un “por las dudas”. O incluso peor! Utilizamos los Try-Catch como If diciendo: “y bueno…si falla…seguro que es la otra opción”, y eso no es programar pragmáticamente.

Meditemos un poco como programamos. Saludos

Cuando necesitás definir una función bastante reusable, y que acepte 1 parámetro genérico del tipo System.Object para después hacer algo con él, cómo se lo pedirias a tu compañero de trabajo:

Opción 1:

“che…y bueno…hacete una función que acepte 1 parametro del tipo Object y entonces despues le pasamos cualquier tipo y despues al objeto adentro, lo casteamos y listo”

Opción 2:

“…yo creo que podrías escribir un método aprovechando el principio de sustitución de Liskov, de modo que después convertimos el parámetro al tipo deseado para trabajar con él.”

Ay mamá! con ese nombre parece que se va a “aparecer” algo!

Para más…acá les dejo un link de la wiki.