Blog

La mayor parte de los problemas que nos podemos encontrar al usar patrones de diseño vienen de no ser capaces de reconocer en qué contextos hay que aplicarlos.

Se han escrito muchas líneas acerca de la seguridad de las aplicaciones que realizamos en .Net. Se dice que son muy fáciles de hackear, que aun usando herramientas de ofuscación, la seguridad de los empaquetados que se distribuyen es nula.

Cuando hablamos de un patrón de diseño nos referimos a una solución a un problema concreto en el desarrollo de software. Pero no cualquier solución, sólo aquellas que se ha desmostrado que son eficientes en diferentes escenarios y reutilizables en gran cantidad de contextos de aplicaciones. Por lo tanto, aunque los ejemplos que podamos dar estén en un lenguaje de programación concreto, la idea será extrapolable a diferentes lenguajes de programación orientada a objetos.

¿Qué desarrollador de software nunca ha estado una semana programando a toda velocidad, casi sin saber que hace, ya que la fecha de entrega está cerca y todo tiene que estar terminado “para ayer”? ¿Quién no se ha encontrado en la situación de saber que está programando una chapuza, pensando que otro día lo mejorará, y ese día nunca llega? ¿Quién alguna vez, al ver una porción de código fuente no ha exclamado indignado: ¡qué narices hace este código! o ¡quién leches lo ha programado!?

Hace unos días en los foros de Windows Communication Foundation de MSDN un usuario preguntaba por la diferencia entre Faults y Exceptions dentro de esta plataforma. La respuesta me llevó a escribir una pequeña introducción a la gestión de excepciones para los servicios WCF que me gustaría ampliar en este artículo. Para los más experimentados resultará un texto algo básico. Para los demás sin embargo, les puede ayudar a programar siguiendo las buenas prácticas en el desarrollo de sus servicios.