12.02.2010

Utilizando Unity para Resolver un Problema de Negocio - 4

Continuando con la serie de posts acerca de como utilizar Unity y aplicarlo a un problema de negocio, vamos a agregar en este post la funcionalidad necesaria para permitir agregar nuevos tipos de usuario sin tener que compilar nuestra capa de negocios. La idea con este post es permitirle al desarrollador crear componentes que puedan ser asociados a la lógica de negocios sin tener que modificar la misma a través de su código, y que simplemente con agregar el nuevo tipo al archivo de configuración de nuestra aplicación, este pueda utilizarlo. Para ejemplificar mejor el problema voy a mostrar un diagrama de como se vería físicamente nuestro programa. El estado actual de la aplicación a nivel de lógica de negocios es el siguiente:

image

La idea de este post es crear un nuevo usuario que se va a llamar usuario federado, el cual no va a formar parte de nuestro proyecto de Core.LogicaDeNegocios, si no que será un dll aparte el cual implementa una clase del tipo IUsuario llamada Usuario_Federado. Nuestro esquema debería verse de la siguiente manera:

image

Como podemos ver en la figura anterior, ahora vamos a agregar un nuevo dll en donde va a residir nuestro nuevo usuario – en color rojo. Lo interesante con esta solución es que vamos a poder agregar en nuestro BL nuevos usuarios sin tener que ir a recompilar ni modificar nuestra lógica de negocios; esto es lo que vamos a hacer en el post del día de hoy – para que el cambio se pueda manejar de la misma manera en la capa de UI vamos a utilizar Prism en post posteriores.

Solución

En primera instancia vamos a crear un nuevo proyecto del tipo librería y le vamos a poner Core.LogicaDeNegocios.Usuario_Federado. Seguidamente procedemos a crear la clase Usuario_Federado la cual es similar a las demas clases que implementan IUsuario definidas dentro de la librería Core.LogicaDeNegocios.dll. El dll que acabamos de crear requiere una referencia al dll donde esta definido el tipo IUsuario, es decir Core.LogicaDeNegocios.dll. El código de esta nueva clase es el siguiente:

using Core.LogicaDeNegocios;

using System.Diagnostics;

namespace Core.LogicaDeNegocios.Usuario_Federado
{
public class Usuario_Federado : IUsuario
{
IEmpresa _empresa;
public IEmpresa Empresa
{
get
{
return _empresa;
}
set
{
_empresa = value;
}
}

public IUsuario Autenticar()
{
Trace.WriteLine("Autenticar Usuario_Federado");
return this;
}

public void Autorizar(object _form)
{
Trace.WriteLine("Autorizar Usuario Federado");
}
}
}


Ahora vamos a modificar el UI para que se puedan crear instancias de la clase residente en este nuevo dll. Agregamos la “empresa D” la cual estará asociada con el Usuario_Federado y luego procedemos a agregar el siguiente código en el botón con el cual estamos cargando el usuario de acuerdo a los datos ingresados.



string _tipoUsuario = string.Empty;
if (cmbEmpresa.SelectedItem.ToString() == "Empresa A")
_tipoUsuario = "usuario";
else if (cmbEmpresa.SelectedItem.ToString() == "Empresa B")
_tipoUsuario = "usuarioWeb";
else if (cmbEmpresa.SelectedItem.ToString() == "Empresa C")
_tipoUsuario = "otroUsuario";
else
_tipoUsuario = "usuarioFederado";
UsuarioActual = AdministradorUsuario.ObtenerInstancia(_tipoUsuario, txtNombreUsuario.Text, txtPassword.Text).Autenticar();



El paso siguiente es modificar el App.Config para mapear el tipo, es decir IUsuario a Usuario_Federado:



      <register type="IUsuario" name="usuarioFederado" mapTo="Usuario_Federado" />


Por último, ejecutamos la aplicación y podemos ver que si seleccionamos la empresa D, obtenemos una instancia del tipo Usuario_Federado.



image



Como se puede ver en la figura anterior tenemos una instancia de Usuario_Federado, yal y como lo esperabamos. Nótese sin embargo que la empresa esta en nulo pese a que tenemos implementada la propiedad Empresa del tipo IEmpresa ¿Qué nos falta? Pues si vamos a utilizar las empresas ya definidas en nuestro dll de Core.LogicaDeNegocios.dll simplemente tenemos que agregar el mapeo de la propiedad y listo.



 <register type="IUsuario" name="usuarioFederado" mapTo="Usuario_Federado" >
<
property name="Empresa" dependencyName ="empresaMap" dependencyType="IEmpresa"></property>
</
register>



El resultado será el siguiente:



image



Es importante darnos cuenta que hemos agregado una nueva entidad de negocios a nuestra lógica de negocios sin necesidad de recompilar la misma, esto nos dará muchas ventajas cuando queramos crear aplicaciones listas para evolucionar en el futuro. En el próximo post vamos a analizar los beneficios de este tipo de arquitecturas y cuales frameworks y aplicaciones utilizan este tipo de diseño.



Technorati Tags: ,,,,

2 comentarios:

Anónimo dijo...

Lo primero decirte que felicidades por tu Blog, es muy útil y está todo muy bien explicado.

Estoy iniciandome en Unity y me ha surgido una duda respecto a este ejemplo. ¿Como ligas una dll externa para que Unity la resuelva?. Entiendo que es necesario referenciarla al proyecto y por ello recompilar. ¿Que sentido tiene entonces Unity? ¿De que sirve poner todo configurable por ficheros .config si es necesario añadir lógica de programación para que Unity sepa que resolver?

Diego Rojas dijo...

Hola, gracias por leer el blog. En realidad no se requiere agregar referencias al dll, el dll se carga vía configuración + uso del Unity, esa es la ventaja de el uso de esta tecnología.

Saludos