MySQL Workbench

MySQL no es mi primera opcion como motor de base de datos, sobre bases de datos open source mi primera opcion es Postgresql, realmente no tengo ninguna razon tecnica para fundamentar mi preferencia sobre una base de datos u otra, es simplemente una cuestion de gustos, creo.

Pero aun y cuando MySQL no es de mi total agrado, no puedo omitir que posiblemente entre las bases de datos open source es la mas popular de todas, y por tal motivo la he tenido que utilizar en algunos proyectos de la escuela.

Una de mis principales desaveniencias con las bases de datos, son las herramientas de administracion y desarrollo, las cuales o son muy malas o son pesimas. Durante mucho, a mi forma de ver, tiempo las herramientas de MSSQL server eran las unicas que ofrecian una buena experiencia - remontandome desde unos 8 años a la fecha -.

Posteriormente Oracle buscando mejorar sus herramientas tuvo varios intentos, hasta finalmente salio a la luz el Oracle SQL Developer, pero por el lado de las bases de datos open source no se veia luz al final del camino; con herramientas basadas en Web, que en lugar de ayudar, causan mas dolores de cabeza.

Por eso el dia de hoy al enterarme que la herramienta MySQL Workbench ha sido anunciada para Linux como para OSX, dio como motivo este post.

Si bien el MySQL Workbench ya funcionaba en Windows, no estaba disponible para otras plataformas (Linux, Solaris, OSX), situacion que va a cambiar con las primeras versiones Alpha a finales de Septiembre y las versiones Beta planeadas para principios del 2009.

No he utilizado el MySQl Workbench, aun, asi que solamente me limitare de momento a decir que se ve como una herramienta interesante que vale la pena tener en cuenta y darle seguiiento a su evolucion. Ya que esten disponibles las versiones Alpha con soporte Linux/OSX tendre la oportunidad de comentar con mas detalle mis impresiones, por lo pronto aqui les dejo unos "screenshots".

Cow Parade se va

Algunas vacas del CowParade que ha llegado a su fin.

Intento de plagio frustrado

El día de hoy sale una nota en el periodico Frontera sobre un intento de plagio fallido contra un arquitecto, ya que el arquitecto fue defendido por los albañiles de la obra que el arquitecto supervisaba, si los albañiles le hicieron frente a los plagiarios con piedras, aun y cuando los maleantes les dispararon.

Gracias a esta ayuda el arquitecto se salvo de ser secuestrado. En si la noticia no es novedad, ya que este tipo de acciones ocurren de manera cotidiana, lo que si es novedad, es que es la primera vez que escucho que alguien le hace frente a este tipo de delincuentes y mas aun, hacen que huyan sin lograr sus objetivos.

Obviamente las autoridades ¨no tienen¨ ni la menor idea de donde están los delincuentes y mucho menos idea de como capturarlos.

El Frontera tiene la opción de poder realizar comentarios sobre las notas, sobre este tipo de hechos, normalmente un grupo de ¨troles¨ se apropian de los comentarios para descalificar e insultan a los gobiernos, policías, partidos políticos, a las personas por su lugar de procedencia; con justificación o sin ella, eso lo dejo a criterio de cada quien, pero esta vez hay un par de comentarios que cito:

"Se solicitan Albañiles para sustituir a toda la policia municipal, ministerial y federal, unico requisito es tener we-bos." del pseudonimo "Pepe Perez" y "SEGURAMENTE LE CARGARAN EL PAGO DE LOS CRISTALES DE LA BLAZER DE LOS SECUESTRADORES AL POBRE ARQUITECTO, ASI COMO LE VAN A ACUSAR DE TENER EN SU CONSTRUCCION "PIEDRAS DE ALTO PODER"", "QUE CONTRATEN A LOS ALBAÑILES LOS EMPRESARIOS PARA CUSTODIA" del pseudonimo "giann ruiz".

Obviamente son en todo de burla a las autoridades, pero, dada la situación, no parase tan descabellado el primer comentario de "Pepe Perez"...

Novedades en SQL 2008: Parte 2

En la parte 1, ya se comentaron algunas de las nuevas características de SQL 2008, en este post comentare algunas novedades relacionadas con el manejo y programación de SQL 2008.

Antes que nada, me llama la atención que algunas de estas novedades, existan ya desde hace algunos años en Oracle, lo que me deja la impresión de que MS-SQL aun esta tratando de alcanzar a Oracle con respecto a funcionalidad.

Adicción en vivo de CPU
Imaginemos el escenario de cierre de mes en una empresa de tamaño medio a grande, los servidores de base de datos están al 100% y todavía faltan algunas hora para que el cierre termine; mientras tanto tenemos por ahí un par de CPU que no se están utilizando en producción porque ya es media noche y producción no trabaja de noche, que desperdicio.

Bueno, pues con SQL 2008 y hardware que soporte la adición de CPUs en vivo, vamos a poder trasladar temporalmente esos CPUs ociosos a nuestro servidor de finanzas para tratar de acelerar el proceso de cierre mensual. De igual forma si nuestro servidor es una maquina virtual también vamos a poder adicionarle mas CPUs ociosos.

Solo basta agregar los nuevos CPUs y ejecutar RECONFIGURE para notificarle al SQL que puede hacer uso de esos CPUs y listo, no es necesario interrumpir el proceso actual, el SQL va a distribuir carga sobre los nuevos CPUs.

Gobernador de recursos
A quien no le pasado que tiene un programa de terceros que hace uso de nuestra base de datos, y el programa es terriblemente ineficiente, y cada vez que se ejecuta "ahoga" al CPU o la memoria, bloqueando otros procesos en el servidor de SQL?, pero el proveedor no ha podido solucionar el problema y el programa es necesario que se ejecute...

Bueno con SQL 2008 vamos a poder limitar esos programas voraces para que usen solo un limitado porcentaje del CPU o de la memoria. A través de grupos vamos a poder catalogar esos procesos "groseros" y restringirlos en el uso de recursos de manera que otros procesos que si se comportan bien, también puedan hacer uso de los preciados recursos.

Filestream
Inicialmente las base de datos relacionales fueron concebidas para almacenar información estructurada en forma de tablas y campos, pero en algunas ocasiones el únicamente guardar esta información no es suficiente ya que puede estar ligada a datos no estructurados como: imágenes, documentos, planos, vídeos, música, etc.

SQL permite guardar este tipo de información no estructurada en forma de BLOB (Binary Large Objects, por sus siglas en ingles), el problema es que tener este tipo de campos en una tabla, provoca una penalización de rendimiento, sobre todo cuando el tamaño de los datos no estructurados es mayor a 1MB.

Por tal motivo SQL 2008 incluye esta característica Filestream, la cual nos permite mover los campos BLOB fuera de la tabla y guardar la información no estructura en el sistema de archivos, manteniendo relación con los datos estructurados.

Esta separación trae como consecuencia mejor rendimiento de lectura en las tablas que tienen un campo Filestream, ademas de que el limite para la información no estructurada es el espacio disponible en el sistema de archivos, mientras que los campos BLOB tienen un limite de 2GB.

SQL Management Studio
El SQL Management Studio también incluye mejoras para ayudarnos al desarrollo de aplicaciones, la primera de ellas, es la inclusión de Intellisense, la que va auto-completando nombre de los objetos en la base de datos conforme tecleamos las primeras letras del nombre. Esta funcionalidad es de mucha ayuda cuando el esquema de la base de datos nos es relativamente nuevo.

La otra mejora, es la inclusión de un depurador para T-SQL, que nos permite ejecutar linea por linea de un procedimiento almacenado o una función, funcionalidad que anteriormente solo estaba disponible en Visual Studio.

Programación
Por el lado de la programación también hay varias mejoras, pero hay dos que en lo personal me llaman la atención.

A quien no le ha pasado que tiene en una tabla un campo datetime y la lógica para un reporte necesitamos hacer un DISTINCT sobre este campo para obtener las fechas donde hubo transacciones en este mes, pero... este campo también tiene la hora en que se capturo la transacción!!, por lo tanto esta solución simple no funciona, hay que buscar alguna forma de "truncar" la fecha, oh pero esperen, no hay una forma sencilla de hacer esto.

Aquí es donde los nuevos tipos de datos entran al rescate: DATE y TIME, si, como posiblemente adivinaron DATE solo almacena la parte de la fecha y TIME solo almacena la parte de la hora.

Por lo tanto para solucionar el problema planteado arriba, basta con realizar un CAST de nuestra campo DATETIME a DATE y vóila, ya podemos realizar el DISTINCT y obtener el resultado que buscamos.

Ahora veamos el problema de que tenemos una tabla con ciertos registros, pero necesitamos actualizarlos a partir de otra tabla, en la tabla fuente tenemos registros que son nuevos, que necesitan ser borrados y que necesitan ser actualizados en nuestra tabla destino.

Lo normal seria escribir la lógica por separado para cada una de las posibles operaciones y de esa forma mantener nuestra tabla destino actualizada, bueno con SQL 2008 se incluye la instrucción MERGE, la cual nos permite sincronizar las dos tablas (fuente y destino) en una sola instrucción.

Merge existía en el beta 1 de SQL 2005, pero misteriosamente desapareció en el beta 2, ahora finalmente llego con SQL 2008.

Por el momento es todo en esta primera y segunda parte sobre las novedades en el SQL 2008. Para mayor información favor visitar la documentación del SQL 2008

Horarios de ISC en el ITT

Los horarios de las carrera ISC del ITT son los siguientes, darle click a la hoja de horarios completa para ir al sitio donde están las imágenes donde se aprecian mejor los horarios para cada semestre.

Para información de la asesoría y la re-inscripcion favor de visitar esta pagina.

La arquitectura de cebolla: parte 2

En la parte 1 se introdujo el patrón arquitectural llamado "La arquitectura de cebolla". Los conceptos de diseño orientado a objetos no es nuevo, pero el agrupar estas técnicas y convenciones en un patrón único, nos da como resultado esta arquitectura propuesta. La idea en general, es que la industria utilice este nombre para comunicar estos conceptos de forma apropiada.

Ejemplo practico
CodeCampServer hace uso de la arquitectura de cebolla. Si estas buscado por una aplicación de ejemplo, completa y funcional, esta es la aplicación a observar. Este ejemplo practico, se basa directamente en el CodeCampServer. Es un ejemplo de una aplicación vertical. El alcance de este ejemplo va a ser muy pequeño, con la finalidad de que sea digerible.

Primeramente comenzaremos con un diagrama para entender donde es que reside el código dentro de las capas de la cebolla.

CodeCampServer hace uso del framework ASP.NET MVC, así SpeakerController es parte de la interface de usuario. Este controlador esta acoplado con el framework ASP.NET. SpeakerController depende de IConferenceRepository y IUserSession (también de IClock, pero vamos a omitir eso). El controlador solo depende de interfaces, las cuales están definidas en la base de la aplicación. Hay que recordar que todas las dependencias van dirigidas hacia el centro.

Ahora vamos a poner nuestra atención a las clases ConferenceRepository y UserSession. Hay que notar que están definidas en capas fuera de la base de la aplicación, y ellas dependen de interfaces también, de manera que puedan ser implementadas por estas clases. Estas dos clases implementan interfaces que existen muy cerca al centro. Al momento de ejecución el contener de Control de Inversión (Inversion of Control) va a buscar en su registro y construir las clases apropiadas para satisfacer las dependencias en el constructor de la clase SpeakerController, aquí se muestra parte del código:

public SpeakerController(IConferenceRepository conferenceRepository,
IUserSession userSession, IClock clock)
: base(userSession)
{
_conferenceRepository = conferenceRepository;
_clock = clock;
_userSession = userSession;
}

Así que al momento de ejecución el contenedor IoC resolverá las clases que implementan las interfaces y las pasa al constructor de SpeakerController. En este punto, SpeakerController pueda realizar su trabajo.

De acuerdo con las reglas de la arquitectura de cebolla, SpeakerController PODRIA hacer uso directo de UserSession, debido a que están ambas clases en la misma capa, pero no así en el caso de ConferenceRepository. El controlador debe de apoyarse en ayuda externa para obtener una instancia de IConferenceRepository. Este patrón es utilizado en toda a aplicación, el contener IoC nos ayuda a que sea transparente para nosotros.

Al final de estas series, el plan es publicar un sistema completo que este basado en esta arquitectura.

Jeffry Palermo CTO de Headspring Systems en Austin, TX, es ademas MCSD.Net, Microsoft MVP, Scrummmaster certificado, líder del grupo Austin .Net, miembro del consejo AgileAustin, ponente de INETA y mentor de INETA.

Innscripciones semestre Ago-Dic 2008 en el ITT

Ya esta proximo a iniciar un nuevo semestre en Instituto Tecnologico de Tijuana, de hecho esta semana inicial las actividades para el proceso de resinscripcion, pero en el sitio web NO HAN PUBLICADO NADA al respecto.

Por tal motivo aqui les proporciono la siguiente informacion que me paso mi hermano.

Primeramente las asesorias academicas empiezan de la siguiente manera - informacion para la carrera de ISC -:

• 13 de agosto, alumnos de los semestres 2, 3 y 4
• 14 de agosto, alumnos de los semestres 5, 6 y 7
• 15 de agosto, alumnos de 8, 9 y otros

Recuerden que hay que pasar a la coordinacion de cada carrera a realizar el horario para el proximo semestre. En esta ocacion alguna "mente brillante" del ITT decidio no publicar los horarios tentativos, para asi llegar a la asesoria con una idea de las materias a tomar.

Las ordenes de reinscripcion para todas la carreras se encuentra aqui. Los datos para el pago son los siguientes:

• Costo de semestre: $1,900.00 MN
• Referencia bancaria: 5200212-8
• Banco: SCOTIABANK INVERLAT
• No. Cuenta: 13002648938

Nota: Los datos anteriores son tomados tal y cual de la pagina del ITT, es responsabilidad de quien los use validar que sean los correctos. No asumo ninguna responsabilidad en caso de no ser los correctos.

Nota 2: El lugar para resincripcion de TODAS LAS CARRERAS va a ser en la unidad Otay (En el centro de computo), no importa si las clases se llevan en la unidad Tomas Aquino.

Ya que han estado preguntando... No hay horarios para las asesorias solo se sabe que van a ser de 9 am a 5 pm el dia que le corresponda a cada quien. La asesoria se va a realizar en la coordinacion de cada carrera. La inscripcion es la que se va a realizar en el centro de computo.!!!

Novedades en SQL 2008: Parte 1

SQL 2008 por fin alcanzo la meta de ser RTM (Release for manufacturing, por sus siglas en ingles), lo que indica que próximamente se podrá adquirir oficialmente; aunque ya esta disponible para los subscriptores que MSDN y TechNET.

Leyendo la documentación, me encuentro con una serie de nueva funcionalidad o funcionalidad mejorada que en lo particular me interesa; por tal motivo, en esta primera parte voy a describir estas nuevas o mejoradas características en relación al motor de la base de datos.

Administración de la base de datos
Compresión en los respaldos: Esta funcionalidad que anterior a SQL 2008 solo encontrábamos con herramientas de terceros, ahora es parte de SQL. A partir de ahora podemos comprimir nuestros respaldos al momento de realizarlos.

La ventajas son que se requiere de menos tiempo tiempo, menos espacio y menor numero de operaciones I/O para respaldar nuestra información.

La desventaja, es que el algoritmo de compresión requiere de mayor uso del CPU al momento de respaldar, lo que puede provocar que ciertas operaciones tomen mas tiempo al momento de realizar respaldos.

Seguimiento de cambios: Esta es una nueva característica que proporciona una forma ligera - la penalización en rendimiento es relativamente baja - para identificar cambios realizados en las tablas de nuestra base de datos. Con este nos podemos olvidar de soluciones ad-hoc que hacen uso de triggers, timestamps y otros trucos, que por lo general son ineficientes y muy específicos para cada aplicación.

El seguimiento de cambios permite escribir aplicaciones de sincronización de una vía con otras bases de datos o bien sincronización de 2 vías, aunque aquí se requiere una mecanismo para la detección de conflictos.

Es importante mencionar que los registros que cambiaron son identificados por medio de su llave primaria, por lo tanto debe de ser una llave única a través de las diferentes bases de datos o aplicaciones que consumen esta información.

Esta característica de alguna forma me recuerda a la característica de replicacion, de tipo merge, aunque en este caso el seguimiento de cambios no incorpora mecanismo para trasladar los cambios detectados a otras bases de datos, tal y como lo hace la replicacion de tipo merge.

Captura de cambio en datos: Esta es otra nueva característica de SQL 2008, que nos permite identificar cambios en nuestros datos, pudiendo determinar que fue lo que se modifico en ellos.

Por ejemplo esta es una característica muy útil para procesos ETL (Extract, Transform, Load) en donde actualizamos los cambios que van sucediendo en nuestra base de datos a un Datamart o Datawarehouse.

La forma como funciona esta característica consiste, primero, en indicar explícitamente las tablas de las que deseamos capturar cambios, estas tablas las ligamos a una instancia de captura que es quien realiza la operación. Posteriormente nuestra instancia va a monitorear el log de la base de datos para poder determinar que registros sufrieron cambios.

Por cada tabla monitoreada se crea una nueva tabla con el mismo schema, en estas tablas copia es donde se guardan los cambios realizados por una operación del DML. En las tablas de captura vamos a encontrar nuevos registros creados, los registros que fueron eliminados y 2 registros por cada actualización, uno con la imagen de como era el registros antes del cambio y otro con el cambio sufrido en el registro.

En caso de que nuestra tabla monitoreada sufra cambios en el esquema el mecanismo de captura de cambios actuara de la siguiente forma:
- Nuevas columnas, estas serán ignoradas por el monitoreo de cambios, si nos interesa que sean monitoreadas, entonces podemos crear una nueva instancia de captura que incluya el nuevo esquema o recrear la instancia actual.

- Columnas eliminadas: En este caso se insertan valores nulos en las columnas que ya no existen

- Cambio de tipo de una columna: Para evitar perdidas en los datos, se creara una nueva columna con el nuevo tipo de dato y ahí se almacenaran los nuevos valores.

Debido a que monitoreo de cambio puede llevar a tener miles de cambios, existe un tiempo de retención, que por omisión son tres días, cambios capturados anteriores a esta fecha son eliminados de la tabla de captura.

Por el momento es todo en esta primera parte sobre las novedades en el SQL 2008. Para mayor información favor visitar la documentación del SQL 2008

La "migra" te puede quitar tus aparatos electronicos

Vas a viajar a Estados Unidos por avión, vía terrestre u otro?, vas a llevar contigo algún dispositivo electrónico o dispositivo de almacenamiento de información como: Computador portátil, celular, CD's, iPod, memorias USB, etc.

Pues cuidado, ya que según Estados Unidos con el afán de detener a esos "terribles" y "malévolos" terroristas, van a poder revisar todos esos dispositivos aun y cuando no exista alguna sospecha sobre ti, es decir cuando se les de la gana, sin importar si eres ciudadano Estadounidense o no.

Ademas de poder llevarse tus equipos para examinarlos en algún otro lugar, copiar tus datos, traducirlos, etc. e inclusive detener tus aparatos por meses, y todo legalmente.

Inclusive se pueden quedar con tus libros y folletos.

Lo único que puedo comentar claramente ante esta situación es: QUE POCA MADRE !!

Nota del periodico Frontera

La arquitectura de cebolla: parte 1

Este post es parte de una serie de post en ingles de Jeffrey Palermo, en ellos se describe lo que Jeffrey llama la "Arquitectura de Cebolla" - Onion Arquitecture -.

La arquitectura aquí descrita es muy apropiada para aplicaciones de negocio con un amplio ciclo de vida o aplicaciones que tienen un comportamiento complejo. Mediante el énfasis del uso de interfaces para los contratos de comportamiento, se fuerza a la externalizacion de la infraestructura.

Arquitectura tradicional en capas

El diagrama 1, muestra la representación de la arquitectura tradicional en capas. Esta es el tipo de arquitectura básica y mas utilizada. Cada capa inferior depende de la capa superior, y a su vez cada capa va a depender de una infraestructura común y servicios comunes.

Diagrama 1: Arquitectura en capas

La gran desventaja de esta arquitectura de capas de arriba hacia abajo, es que crea acoplamientos fuertes, es decir cada capa es acoplada a las capas inferiores, y cada capa es también acoplada con varias partes de la infraestructura que tienen diferentes preocupaciones. Aunque, sin acoplamiento, nuestros sistemas realmente no harían nada útil, el problema es que esta arquitectura tradicional crea acoplamientos innecesarios.

El problema principal (y también el mas común) es el acoplamiento entre la UI (interface de usuario, por sus siglas en ingles) y la lógica de negocios para acceder a los datos. Sí, la UI esta acoplada con el acceso a datos en esta arquitectura, dependencias transitivas continúan siendo dependencias; la UI no puede funcionar sin la lógica de negocios y la lógica de negocios no puede funcionar sin el acceso a datos; intencionalmente ignoramos la infraestructura, ya que esta puede variar de sistema a sistema.

Las técnicas de acceso a datos cambian frecuentemente, históricamente, la industria a modificado estas técnicas por lo menos cada tres años, por lo tanto, posiblemente en tres años vamos a tener que modificar sistemas sanos, de larga vida que son de misión critica para los negocios. Los sistemas no son actualizados para mantenerse al día, debido a que es muy difícil lograrlo, por lo tanto si el acoplamiento impide el actualizar fácilmente partes del sistema, no queda otra opción que despreciar el sistema y dejar que se convierta en obsoleto. Así es como un sistema heredado - legacy - se congela en el tiempo, y eventualmente es reemplazado por uno nuevo.

Arquitectura de Cebolla

Aquí es donde entra la arquitectura de cebolla, que si bien no es algo nuevo, si se propone este nombre para identificar este patrón arquitectural. Los patrones son útiles debido a que proporciona a los profesionales del software un vocabulario común mediante el cual comunicarse. En la arquitectura de cebolla existen varios aspectos, que si tenemos un termino común para describirlos, entonces nos podemos comunicar eficientemente.

El diagrama 2 muestra esta arquitectura. La parte importante es que controla el acoplamiento; como regla general, todo el código puede depender de capas centrales, pero no puede depender de capas fuera de la capas base - core -. En otras palabras, el acoplamiento se dirige hacia el centro. Esta arquitectura favorece la programación orientada a objetos.

Diagrama 2: Arquitectura de cebolla

En el centro podemos observar el dominio de modelos - Domain model -, que representa la combinación de estado y comportamiento de los modelos a través de la organización. Alrededor del dominio de modelos existen otras capas que incluyen mas cuestiones de comportamiento. El numero de capas de la base de la aplicación puede variar, pero hay que recordar que siempre el domino de modelos esta en el centro y debido a que las capas se acoplan al centro, el dominio de modelos solo puede acoplarse a si mismo.

La primera capa alrededor de nuestro dominio de modelos, es donde típicamente encontramos las interfaces que nos van a proporcionar el comportamiento para guardar u obtener un objeto, esta capa se llama las interfaces de repositorio. El guardar o leer un objeto, no es un comportamiento de la base de la aplicación, ya que típicamente esto es competencia de la base de datos; así que solo la interface con este comportamiento es la que se encuentra en la base de la aplicación.

En las orillas de nuestro diagrama vemos la UI, infraestructura y las pruebas, esto se debe a que la capa exterior es reservada para los artefactos que cambian constantemente; por lo tanto estos deben de ser intencionalmente aislados de la base de la aplicación. Ahí mismo en la orilla nos encontraremos con alguna clase que implemente la interface de repositorio. esta clase va a estar particularmente acoplada al método de acceso a datos, y es por eso que reside fuera de la base. Debido a que esta clase implementa la interface repositorio, esta clase esta acoplada a la interface.

La arquitectura de cebolla se apoya plenamente en el principio de Dependencia Inversa - Dependency Inversion -. La base de la aplicación necesita de la implementación de las interfaces base, y si las clase que las implementas existen en los bordes de la aplicaciones, entonces necesitamos de algún mecanismo que "inyecte" esas clases al momento de ejecución de la aplicación, para que así, haga algo útil.

Un cambio importante es esta arquitectura es, que la base de datos no es el centro, si no un recurso externo. Externalizar la base de datos puede ser un reto para algunas personas que piensan en las aplicaciones como aplicaciones de datos. Con la arquitectura de cebolla, no hay aplicaciones de datos. Pueden existir aplicaciones que podrían hacer uso de las base de datos como un servicio de almacenamiento, pero solo a través de alguna infraestructura externa de código, que implemente las interfaces que hagan sentido para la base de la aplicaciones. Desacoplar las aplicaciones de las bases de datos, sistemas de archivos, etc. minimiza el costo de mantenimiento durante la vida de la aplicación.

Alistar Cockburn ha escrito sobre la arquitectura hexagonal; tanto esta la arquitectura hexagonal como la arquitectura de cebolla comparten la siguiente premisa: Externalizar la infraestructura y escribir un adaptador en código de manera que la infraestructura no tenga un acoplamiento fuerte con la aplicación.

En los siguientes posts se hablara mas detalle acerca de esta arquitectura.

Jeffry Palermo CTO de Headspring Systems en Austin, TX, es ademas MCSD.Net, Microsoft MVP, Scrummmaster certificado, líder del grupo Austin .Net, miembro del consejo AgileAustin, ponente de INETA y mentor de INETA.