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.