Archivo por meses: abril 2006

Referencias de Framework

Deja un comentario

El otro día me encontré con Alejandro Pacheco y me paso unos links que están muy buenos en los temas de Framework.

 

•          [Rob96] Roberts D., Johnson R. (1996). Evolving Frameworks. Don Roberts Home Page. Tomado de http://st-ww.cs.uiuc.edu/~droberts/evolve.html en abril de 2006.

•          [Yod97] Yooder J., Foote B. The Selfish Class. Conference on Patterns Languages of Programs. Monticello, Illinois, September 1996.  Tomado de http://www.joeyoder.com/papers/papers.html en Abril de 2006.

•          [IBM97] IBM. Taligent. Building Object-Oriented Frameworks. LHCb Computing Home Page. Tomado de http://lhcb-comp.web.cern.ch/lhcb-comp/Components/postscript/buildingoo.pdf  en Abril del 2006

•          [Chen04] Chen X. (2204) Developing Aplication Frameworks in .NET. APRESS 2004

•          [Joh03] Johnson R. (2003). Expert One-on-One J2EE Design and Development. Wiley Publishing, Inc.

•          [Rae06] Definición de Tecnología. http://www.rae.es

•          [CMP06] Definición de API http://www.computer-dictionary-online.org

 

Desde una arquitectura muy conocida a una implementación caótica.

1 respuesta

Todo el mundo habla de desarrollo en capas, los arquitectos de software en reuniones pomposas se llenan la boca con Acrónimos tales como SOA, Event Driven, AOP, OOP etc.

 

Los Developer escuchan esas conversaciones crípticas y piensan ufff que saben estos tipos, no soy digno de conversar con ellos.

 

Cuando terminan esas reuniones pomposas, los arquitectos se van para la casa y los Developer deben implementar todas esas maravillas,  muchas veces estos tipos de alta alcurnia computacional no bajan sus ideas cósmicas al nivel de la tierra, altura donde el software es construido y ejecutado.

 

Bajar de los 10.000 metros a tierra las arquitecturas, es el trabajo de la disciplina del diseño. Cómo implica trabajo, los arquitectos no lo hacen y muchas veces nadie lo hace y el Developer debe “asumir” esa responsabilidad.

 

Una de las principales falencias de la arquitectura en capas, es una guía clara de cómo manejar los datos de negocio entre esas capas. Por supuesto todos hablan de DALC, BLL, Entidades de negocio, CRUD, pero frecuentemente no se explica el escenario general y los criterios que se debe usar para las decisiones de diseño.

 

En este contexto aparecen preguntas como las siguientes:

 

  • ¿Cómo represento una entidad de negocio?
  • ¿Cómo represento una colección de entidades?
  • ¿Cómo represento la jerarquía?
  •  ¿Qué formato de datos usamos para acceder al DALC?
  • ¿Cómo me abstraigo de la capa de datos?
  • ¿Cuándo uso Store Procedure y cuándo no?

 

Estos temas son los en que la gente común, Developer y diseñadores, necesitan guías para hacer su trabajo del día a día. Por su lado los arquitectos pueden seguir en los 10.000 metros, repitiendo sus mantras y dibujando el futuro.

Próxima conferencia técnica.

Deja un comentario

Desarrollo basado en capas: lo que quieres saber del diseño y desarrollo de componentes de una aplicación dividida en capas.

 

Desde hace un tiempo todo el mundo habla de arquitectura en capas, esto es un patrón de programación en la que el objetivo primordial es la separación de las responsabilidades en diferentes capas para simplificar el entendimiento del sistema y su diseño; sin embargo, complica la implementación. Un ejemplo básico de esto es separar la capa de datos, negocio y de presentación al usuario. La ventaja principal de este patrón, es que el desarrollo de las capas puede ser hecho en paralelo y en caso de algún cambio sólo se modifica la capa en cuestión sin intervenir las otras.

Normalmente se explica sólo la importancia del aislamiento entre las capas y sus responsabilidades, pero ¿cómo hacerlo? Cuando se diseña una aplicación en capas es necesario definir cómo acceder y representar los datos de negocio de la aplicación. En esta conferencia mostraremos guías prácticas que ayudan a elegir la manera más apropiada de exponer, persistir y pasar los datos a través de las capas de la aplicación. Aclararemos la diferencia entre los datos de negocio y los procesos de negocio que los usan. Será una conferencia dónde se verán ejemplos prácticos y muchos casos del tipo “HOW TO”, basados en lecciones aprendidas en proyecto reales de desarrollo de software en Chile.

¿A que fui a Argentina?

Deja un comentario

Eso se preguntan varios, mi jefe entre ellos 😉

 

En esto andaba:

 

Encuentro Regional de MVPs

 

A comienzos de abril se realizó en Buenos Aires un encuentro de los MVPs del Cono Sur. Los Microsoft Most Valuable Professionals son personas reconocidas por su contribución a la comunidad, por dar charlas (en eventos MSDN o en universidades) o participar en foros respondiendo preguntas y compartiendo sus conocimientos. Una vez al año se reúnen representantes de todos los países para intercambiar entre ellos experiencias acerca de las comunidades de desarrolladores de cada país y así cada uno regresa con nuevas ideas y entusiasmo para seguir entregando más y mejor conocimiento. El título de MVPs es honorífico (no rentado) y refleja el esfuerzo anual por las contribuciones que realiza. Los MVPs suelen tener distintos niveles de intercambio con los grupos de producto de Microsoft y en más de una ocasión sus recomendaciones se transformaron en cambios concretos en las versiones siguientes.