Estimados lectores, siempre he creeido en las cadenas de favores por lo que en esta ocasion la vacante a la cual hago referencia no es directamente en IT Builder, pero definitivamente es una excelente oportunidad que una amiga personal tiene para un arquitecto en .NET de buen nivel, si alguno esta interesado debera mandar su CV a la siguiente direccion fflores@bakertillymexico.com (sean serios y profesionales por favor, solo envien curriculum aquellos que ya tengan experiencia en el rol y que de verdad sean arquitectos), la vacante es en MTY y en caso de estar interesados en algun perfil ellos se pondran en contacto con ustedes (asi que asegurense de proporcionar sus datos de contacto)

Suerte

Descarga en PDF la edicion numero 23 de The Architecture Journal

 AJ23_EN.zip (1.98 mb)

 Descarga en PDF la edicion numero 22 de The Architecture Journal

 AJ22_EN.zip (3.95 mb)

Descarga en PDF la edicion numero 21 de The Architecture Journal

AJ21_EN.zip (2.53 mb)

Definiciones de conversión entre estructuras relacionales y objetos (Object Relational Mappers)

En el capítulo 3 hicimos nuestro primer esfuerzo para unir el mundo de los objetos con los datos mediante la escritura a mano de nuestra propia capa de acceso a datos y su definición de conversión. Este enfoque resultó ser más bien limitado y requirió una cantidad significativa de código repetitivo (aunque  fue útil para demostrar las bases).  Agregar más objetos y funcionalidad sobrecargaría nuestro Capa de Acceso a Datos (DAL) en una enorme violación inmanejable del principio que dicta ‘No te repitas a ti mismo’ (DRY, por sus siglas en inglés). En este capítulo veremos un marco de trabajo real para la definición de conversiones entre Objetos y Entidades Relacionales (O/R Mapping) que haga todo el trabajo pesado por nosotros. Específicamente veremos el popular marco de trabajo de código abierto llamado NHibernate.

La única y más grande barrera que impide a la gente adoptar el diseño guiado por el dominio (DDD por sus siglas en inglés), es el problema de la persistencia. Mi propia adopción de las definiciones de conversión entre estructuras relacionales y los objetos (O/R Mappers) inicio con gran confusión y duda.  Básicamente se te pedirá que cambies tu conocimiento de un método probado  por algo que parece de un poco mágico.  Puede ser requerida algo de fe ciega.

La primer cosa con la que hay que llegar a un acuerdo es con que las definiciones de conversión generan tu SQL por ti, lo sé, suena como que será algo lento, inseguro e inflexible, especialmente debido a que probablemente imaginaste que se tendría que usar SQL en línea. Pero sí puedes quitarte esos miedos de tu mente por un segundo, tienes que admitir que podría ahorrarte mucho tiempo y tener como resultado un número mucho menor de defectos. Recuerda, queremos enfocarnos en construir el comportamiento, no preocuparnos con cuestiones de interconexión (y si te hace sentir mejor, una buena definición de conversiones entre estructuras relacionales y objetos te proveerá formas sencillas de desactivar la generación automatizada de código y ejecutar tu propio SQL o tus procedimientos almacenados).

La incorporación de patrones es muy importante pues en un escenario como el anterior y ayudado de políticas de codificación te puede ayudar a establecer los parámetros mediante los cuales se le permite al equipo trabajar, pero no solo eso, los patrones nos dan una forma de resolver un problema común, retos a los que alguien mas ya se enfrento en su momento y para lo cual genero una solución, algo probado que sabes que funcionará, esto te ahorrará mucho tiempo en la conceptualización y el diseño, los patrones también como base para el establecimiento de mecanismos de generación automática de código por lo menos a nivel de proxys o contratos , es decir … que una vez establecido un patrón para cierto componente o parte de la aplicación puedes generar cuando menos platillas automáticas que te generaran el esqueleto, más aun, la aplicación de los patrones hacen que el costo de mantener,  modificar y extender tus módulos o la aplicación completa, sea infinitamente menor … algo que seguramente apreciarás cuando el cliente te pida cambios o adecuaciones ‘menores’  que sin la incorporación de patrones te tomaría meses … el tiempo invertido en el diseño puede ser el factor clave que te permita hacer esos cambios en solo días … incluso horas o minutos.

Aquí les dejo un reporte generado por Nucleus Reseach dedicado precisamente a analizar las ventajas de incorporar los patrones a sus proyectos de construcción de software.

A lo largo de mis años en la industria del desarrollo de software he tenido la fortuna de vivir en carne propia ambas caras de la moneda en cuanto al uso e implementación de de patrones, desde el desarrollo con un uso nulo de los mismos (en mis primeros años) hasta el uso extensivo y casi religioso de un conjunto bastante extenso. ¿Y porque digo que he tenido la fortuna de vivir ambos?, bien pues básicamente por que el pasar por la experiencia de no usarlos y después dedicar tiempo significativo en su evaluación e incorporación dentro de los proyectos solo me ayudó a entender el por qué son tan importantes, en el aspecto práctico el uso de patrones en el diseño de la arquitectura de software puede marcar la diferencia entre el éxito y el fracaso de un proyecto … crees que exagero ? ok, imagina que debes realizar un producto muy grande en donde por el tamaño necesitas que tu equipo esté formado por varios desarrolladores, cada uno con diferente nivel de experiencia (incluso en el manejo de la tecnología), cada uno con una forma de ver el producto y por supuesto cada uno de ellos con una manera diferente de enfrentar los retos tecnológicos que implica la construcción de la aplicación.

Hace algunos meses platicando con un cliente y amigo personal me inquieto un poco la percepción que se tiene respecto a lo que es computo en la nube y las nuevas tendencias orientadas hacia este tipo de plataformas globales... en aquella ocasión el me comentaba que algunos de sus productos ya estaban orientados desde hace algunos años al nuevo paradigma de ‘computo en la nube’, aun cuando su estrategia comercial de ‘Software As A Service’ me parecía muy inteligente, ésta mas bien se trataba de la venta de licenciamiento del software que ‘hosteaba’ en sus servidores. Con la nueva oleada de tecnologías y formas de conceptualizar la oferta de servicios en línea considero importante el establecer claramente las diferencias entre lo que es Hosting VS. Cloud computing, es por eso que aquí les comparto un muy buen documento de introducción a Azure escrito por David Chapell, no olvides visitar: http://www.microsoft.com/windowsazure/  

Windows Azure Platform, v1.2--Chappell[1].pdf (1.08 mb)

Les comparto algunas ligas que les pueden ser de mucha utilidad si requieren entrenamiento o informacion de las herramientas con las que Microsoft cuenta para los que nos dedicamos a la industria de TI.

• Windows 7x7
• Community Media Center
• Microsoft Virtual Academy
• Techcenter de Windows
• Desarrollador 5 Estrellas
• MSDN Flash
• Bloggers de Microsoft

Una de las desiciones mas importantes a las que un equipo de desarrollo se enfrenta cuando un proyecto de desarrollo se encuentra en sus primeras fases, es la de evaluar y seleccionar la estrategia de diseño que será la base para establecer la arquitectura de la aplicación, como algunas veces he comentado, mi punto de vista personal es que no existe una forma correcta o incorrecta de establecer el diseño conceptual (asumiendo que se cuente con ´proven practices' y con buen nivel técnico) ya que en gran medida esto depende de las características funcionales que se busca incorporar, sin embargo muchas veces este proceso se vuelve complejo cuando nos topamos con diferentes formas y tecnologías de implementar un mismo esquema (ej. un flujo de trabajo), la buena noticia es que no es necesario invertir mucho tiempo realizando pruebas de concepto para ver que estrategia funciona mejor para las características de la solución aqui les comparto un par de ligas que pueden serles de mucha utilidad para evaluar patrones de arquitectura, conocer soluciones probadas para problemas comunes, guias de diseño y codigo fuente de ejemplo.

 Have Fun :)

patterns & practices: App Arch Guide 2.0 Knowledge Base

patterns & practices: Data Access Guidance