iHenry Smith

Iniciando nServiceBus con un ejemplo en GUI

ihenrysmith — Sun, 26 Dec 2010 18:35:46 +0000

Algunos nos hemos topado que cuando queremos comenzar a utilizar nServiceBus los ejemplos pueden ser un poco confusos. Notamos que utilizan NServiceBus.Host y cuando abrimos la “solución” del Visual Studio parece que todo sucede por arte de magia. Esto es lo bello del nServiceBus, que te implementa gran parte del trabajo de una forma elegante, flexible y probada. Sin embargo en este ejemplo dejaremos el NServiceBus.Host de lado y levantemos el Bus utilizando una forma gráfica.

El Concepto

No me voy a referir mucho al tema de ¿qué es nServiceBus? o sobre ¿qué es lo que hace y qué no hace?. Por lo pronto solo voy a mencionar algunas dudas primarias que surgen al iniciar en este mundo.
nServiceBus:

No está hecho para remplazar WCF, puede por el contrario complementarse con WCF.
No es un Broker, no viene a remplazar Biztalk por ejemplo.
No está echo para problemas en los que se requiere comunicación sincrónica, aunque puede emularla.
Esta echo para hacer Publish-Subscriber bien.
El canal principal de comunicación son las colas (queues), igual, pueden utilizarse otros medios, pero el más natural son las colas.
Es un proyecto creado y administrado por Udi Dahan, no es proyecto Microsoft, ni está en CodePlex. Inició Open Source hasta el RTM 2.0, pero debido a su aceptación y alegando la necesidad de salvarlo de su propio éxito se creo un Branch comercial a partir de la versión 2.5 en la cual la licencia se cambió y se estableció un sistema de licenciamiento, con restricciones para la versión para la comunidad que parte comercial provee. Se mantiene una versión para la comunidad en la versión 2.0 .

Recursos

La pagina de la versión Open Source Home donde se puede encontrar los ejecutables, documentación, ejemplos e información en general sobre el proyecto.
La versión comercial Home con su sistema de licenciamiento.
El wiki oficial. Cuando era un proyecto Open Source si bien no era muy buena, si era mejor que la de muchos proyectos de código abierto. Ahora con la nueva faceta comercial esperamos una mejora importante.
El código fuente en sourceforce por si nos interesa contribuir con el proyecto o entenderlo a fondo. El lado comercial se migró a GitHub, donde se puede encontrar el código con restricciones.
Foro de discusión una parte importante que he notado es que este foro es muy activo y el mismo Udi Dahan constantemente está colaborando en las discusiones. Es un yahoo group, muchos como yo, probablemente se verán forzados ah abrir una cuenta en yahoo.

El Ejemplo

El ejemplo es simple e integra dos patrones el Publish-Subscriber y el Request and Response . Un cliente (Subscritor) que espera alertas y un servidor (Publicador) que dispara alertas a sus subscriptores. A su vez el cliente puede validar una dirección de correo electrónico contra el servidor, de la forma Request and Response.

Para el ejemplo se debe tener MSMQ instalado, para ello se puede correr el bat que viene con los binarios del nServiceBus RunMeFirst.bat con privilegios de administrador de la forma: RunMeFirst.bat /i

Para descargar el ejemplo

Los Mensajes

En nuestra solución lo primero que hacemos es crear un proyecto (Library) que contenga los mensajes que serán transmitidos por el bus. Para ello agregamos el DLL NServiceBus y heredamos nuestras clases mensaje de la interface IMessage. Estos mensajes serán DTOs y los atributos tienen la restricción de que deben ser serializables

using System;
using NServiceBus;

namespace Messages
{
   [Serializable]
   [TimeToBeReceived("00:00:30")]
   public class Alert : IMessage
   {
      public string From { get; set; }
      public string AlertType { get; set; }
      public DateTime Date { get; set; }
      public WireEncryptedString AlertMessage { get; set; }
   }
}

En TimeToBeReceived se indica que se dan 30 segundos para que el mensaje sea recibido, de lo contrario se borrara. WireEncryptedString es una clase que provee nServiceBus y nos permite enviar un texto encriptado.

El Server (Publisher/Publicador)

Comenzaremos por el servidor. Lo primero será crear y configurar las secciones del nServiceBus

En MsmqTransportConfig lo que hacemos es configurar las colas de transporte, la primera InputQueue es por la cual el servidor escuchará los mensajes y en la segunda ErrorQueue se escribirán los errores . En UnicastBusConfig se configura el bus y los EndPoints, pero en este caso el servidor no expondrá ninguno.

Inicializamos el Bus

_bus = Configure.With()
	.CastleWindsorBuilder() //Vamos a utilizar Windsor en vez de Spring
	.XmlSerializer() //Serialización por XML
	.MsmqSubscriptionStorage() //Guardamos los Subscriptores en una cola
	.MsmqTransport() // Transporte por colas
  	    .IsTransactional(true)
	    .PurgeOnStartup(false) //Limpiar las colas al Iniciar
	.UnicastBus() //El bus (única opción disponible)
	.ImpersonateSender(false)
	.LoadMessageHandlers() //Cargar los handlers al iniciar
	.RijndaelEncryptionService() //Usar el servicio de encriptación
	.CreateBus() // Crea el bus
	.Start();    //Inicial el bus

La mayoría de las cosas suceden por IoC. Por defecto nServiceBus usa Spring como contenedor IoC, en este caso lo cambiamos a usar CastleWindsor del Castle Project solo para ilustrar el cambio (esto obliga a agregar los DLLs del Castle a la solución) . LoadMessageHandlers() inspecciona el assembly y carga los Handlers que existan en este, más adelante veremos como esto nos puede complicar la existencia cuando intentemos pasar los response de los handlers al hilo principal del despliegue gráfico.

Publicar un mensaje

Para publicar un mensaje lo único que se hace es llamar al método Publish del bus y nServiceBus se encarga del resto.

_bus.Publish(new Alert()
{
       Date = DateTime.Now,
       AlertMessage =
       string.Format("Transmitted encrypted Alert Message: {0}",
       txtAlertMessage.Text),
       From = Environment.MachineName,
       AlertType = "info",
});

Handlers

Los podemos ver como hilos que son disparados cuando se recibe un mensaje del tipo que ellos esperan

public class ValidateEmailHandler : IHandleMessages
{

    #region Members
    private string _strRegex = @"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}" +
                @"\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\" +
                @".)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";
    #endregion

    #region Properties
    public IBus _bus { get; set; }
    #endregion

    #region Handle Method

    public void Handle(ValidateEmailRequest message)
    {

        Regex re = new Regex(_strRegex);
        var response = _bus.CreateInstance(attributes =>
        {
            attributes.IsValid = re.IsMatch(message.Email);
        });
        response.CopyHeaderFromRequest("Test");
        response.SetHeader("ValidatedEmail", message.Email);
        _bus.Reply(response);
    }

    #endregion
}

En este caso el nServiceBus al recibir un mensaje de tipo ValidateEmailRequest dispara el handler ValidateEmailHandler.

El Cliente

La configuración del cliente es prácticamente igual, solo que en este caso si exponemos un EndPoint indicando cuales mensajes queremos escuchar y por cual cola.

La configuración del bus es similar. Aquí lo único que estoy agregando es un registro a una instancia singleton que actúa de mediador entre los handlers y el GUI.

            _bus = Configure.With()
                .CastleWindsorBuilder()
                        .RunCustomAction(() =>
              Configure.Instance.Configurer.RegisterSingleton(Mediator.Instance))
                .XmlSerializer()
                .MsmqTransport()
                    .IsTransactional(false)
                    .PurgeOnStartup(false)
                .UnicastBus()
                    .ImpersonateSender(false)
                .LoadMessageHandlers()
                .DoNotAutoSubscribe()//Evita que se auto-subscriba al inicial la aplicación
                .RijndaelEncryptionService()
                .CreateBus()
                .Start();

Subscribirse/Des-subscribirse

Tan simple como decir a qué tipo de mensaje nos estasmos subscribiendo o a cuál nos des-subscribimos

_bus.Subscribe();
_bus.Unsubscribe();

Handlers

AlertHandler es quien recibe las alertas, en este caso utiliza el mediador para notificar al GUI.

public class AlertHandler : IHandleMessages
{
    #region Properties
    public IBus Bus { get; set; }
    //Mediator es inyectado por el IoC
    public IFFMediator Mediator { get; set; }
    #endregion

    #region Handle Method

    public void Handle(Alert message)
    {
        Mediator.NotifyMessageAlert(message);
    }

    #endregion

}

Request-Response

Enviamos un mensaje para validar el Email y registramos una acción que se ejecutara al momento de recibir una respuesta. Igualmente podríamos colocar un handler para que maneje estas respuestas. Aquí notamos que el registro de la acción está en otro hilo por ello utilizamos Invoke.

_bus.Send
                (x => { x.Email = txtEmailToValidate.Text; }).Register(
                    whenCallback =>
                    {
                        // Saca el email validado de los Headers
                        string email = _bus.CurrentMessageContext.Headers["ValidatedEmail"];
                        // response message.
                        NServiceBus.CompletionResult completionResult =
                            whenCallback.AsyncState as NServiceBus.CompletionResult;
                        if (completionResult != null)
                        {
                            foreach (var item in completionResult.Messages)
                            {
                                Invoke((Action)(() =>
                                {
                                    lblValidationResult.Text =
                                        ((ValidateEmailResponse)item).IsValid ? "Valid" : "Invalid";
                                    lblValidatedEmail.Text = email;
                                }));
                            }
                        }
                    }, null);

Conclusiones

La configuración y los ejemplos son bastante simples. Al principio lo que nos puede costar es entender el concepto y principalmente donde aplica y donde no aplica.

GUI…

Lo que no me gusta de los ejemplo que vienen con los binarios, es que todos están sobre consola y utilizan NServiceBus.Host. Al intentar pasarlo a un GUI no nos puede resultar realmente claro que es lo que sucede con los handlers, dado que estos son cargados automáticamente por el bus cuando inicia. Al suceder de este modo no podemos enlazarlo de una manera directa con nuestra interfaz gráfica ya que no tenemos acceso a este proceso. Sacha Barber en un excelente articulo que escribió en Code Project comenta un par de formas para lidiar con este tema. Particularmente me parece interesante una librería que el mismo Sacha escribió cinch y que es una implementación del patrón mediador que viene a resolver este problema. Igualmente en el mismo foro de nsb, se pueden encontrar algunas otras soluciones. En el caso del ejemplo se utiliza una solución que Udi Dahan propone en el articulo de Sacha y que es una implementación simple de una instancia estática que se registra al bus, lo que permite su inyección a los handlers actuando como mediador entre estos y el GUI.

nServiceBus 2.0, 2.5, 3.0 y más allá….

El ejemplo está montado con 2.0, el ultimo RTM Open Source, como dije anteriormente el 2.5 ya viene con código propietario y para el 3.0 se esperan grandes cambios entre los principales, sacarán el nsb de sus limites de LAN y lo ampliarán a la nube, además de mejoras en el TimeOutManager, el Distribuidor entre otros.

Si utilizan Castle Windsor, el nsb viene con la versión 1.1, sin embargo este proyecto ya está en su versión 2.5.2 y se espera la 3.0 para el primer cuatrimestre del 2011. Para usar otras herramientas que provee el Castle Project como los facilities para la integración con WCF deberemos bajar las fuentes y re-compilar NServiceBus.ObjectBuilder.CastleWindsor.

Tip: Expresión Regular para remover el número de línea

ihenrysmith — Fri, 09 Apr 2010 06:41:00 +0000

Algunas veces encontramos un código interesante en algún web, pero viene con la útil pero molesta numeración de línea, que al copiarlo se viene en combo.

Algo que solemos hacer cuando hacemos una búsqueda es ignorar las expresiones regulares, lo cuál es una pena, ya que aplica en muchas situaciones que pueden volvernos la vida mucho más fácil y el caso de las líneas es un ejemplo claro ya que con una simple expresión regular nos deshacemos ellas al instante.

Ejemplo

Yo uso el editor notepad++ (el cual recomiendo sobre manera) y la expresión a usar sería:

^[\s*+\d]+:

Si usamos Visual Studio sería similar en forma:

^ *[0-9]+\:

(Notese que hay un espacio en blanco entre ^ y * )
Otro sencillo ejemplo que lo complementa, es remover las líneas en blanco para lo cuál usamos en el Visual Studio: ^$\n

Las expresiones regulares son un arte, y es bueno que las incluyamos con más frecuencia en nuestro que hacer diario. Si bien, poco a poco, las herramientas nos facilitan mucho más la vida, no debemos olvidar las expresiones, recordemos el poder de grep y perl, todo lo que podemos hacer con unas simples lineas bien escritas.

/(bb|[^b]{2})/

Mock objects (Objetos Simulados)

ihenrysmith — Mon, 22 Mar 2010 03:55:00 +0000

Con Mock Objects lo que hacemos es simular el comportamiento de los objetos “reales” pero de manera “controlada”.

Muchas veces cuando queremos crear pruebas para algún objeto nos topamos con el problema de que tiene dependencias, esto nos obliga a buscar la forma para proveerlas, esta situación se puede complicar más cuando estas dependencias aún no han sido programadas, inclusive , tendiéndolas, nos va a llevar mucho trabajo configurar el contexto y conocer que exactamente se les está suministrando y que es lo que nos están proveyendo. Poco a poco nos vamos metiendo en un desorden de miedo, por ejemplo al fallar una prueba nos va costar determinar si fue el objeto “target” el que falló o alguna de sus dependencias y de ser este el caso, es algo que realmente no nos interesa mucho, ya que NO son las dependencias las que estamos probando.Para aislar las pruebas, al punto que las podamos hacer realmente unitarias, utilizamos “mocks“, que permitan grabar el comportamiento del objeto con aquellos con los que tiene relación. Con los “mocks” proveemos datos y comportamiento totalmente controlados de manera tal que sabemos exactamente que es lo que le estamos proveyendo al objeto, que nos está mandando y que deberíamos esperar.

En la teoría siempre citan el ejemplo de las pruebas de carros, en donde ponen maniquíes especiales que simulan (“mock“) personas reales para ver como reaccionan al choque, esto, dado que es imposible probar con personas reales.

Cuando vamos a implementar mocks, salta la pregunta de cuál framework deberíamos usar. Como es de esperar existen varias opciones, no hay un consenso ya que cada quien tiene su sabor favorito. Entre los principales frameworks actualmente se encuentran NMock2, Moq, Rhino, Isolator. Existen varias comparaciones esta particularmente es corta y concisa. Lo que puedo decir rápidamente basado en la comparativa: NMock2 es “Type unsafe” lo que implica que espera strings lo cual es algo que particularmente no me gusta ya se vuelve muy desordenado y delicado, además no hay apoyo del Intelicense, Moq es el que usamos actualmente y es simple y fácil de aprender ya que es muy intuitivo, recientemente me topé con el problema de que no soporta output parameters y los callbacks tienen un límite de cuatro parámetros, actualmente hay una versión en beta. Rhino si bien no lo he usado mucho he visto que tiene buena aceptación en los foros aunque desde la aparición de Moq ha ido perdiendo terreno. Isolator no es open source y no es gratuito lo que le hace perder muchos puntos cuando el presupuesto es importante, además, según la comparativa es el más lento.

Ejemplo con Moq

Moq es relativamente nuevo, pero ha tenido buena aceptación. Para el ejemplo estoy usando la versión 3.1.416.3 junto con NUnit 2.5.9222 y el .Net Framework 3.5

Supongamos que tenemos un pequeño web que registra usuarios tomando alguna información mínima. Existen dos servicios uno de datos (IUserDataService) y otro de formato (IUserFormatingService) los cuales son utilizados por un tercer servicio (IUserService) que funciona como un facade para juntarlos y dar acceso a las operaciones.

public interface IUserFormatingService
{
User FormatUserRaw(DataRow row);
}

public interface IUserService
{
int Add(User user);
}

public interface IUserDataService
{
int AddToDB(User user);
bool IsLoginNameAvailable(string LoginName);
}

IUserService se encarga de validar el DTO User e insertarlo en la Base de Datos, para ello utiliza el método IsLoginNameAvailable para verificar que el Login está disponible y AddToDB que se encarga de la inserción propiamente dicha.

La entidad User tiene unas pocas propiedades

public class User
{
public int ID { get; set; }
public string Name{ get; set; }
public string Login { get; set; }
public string Password { get; set; }
public string Email { get; set; }
public string Country { get; set; }
public double Balance { get; set; }
public DateTime BirthDate { get; set; }
public DateTime SingUpDate { get; set; }
}

La implementación UserService, como curiosidad, podríamos pensar que los dos servicios que está esperando en el constructor son provistos por una entidad aparte que se encarga de inyectarlos y por tanto estamos usando IoC.

public class UserService : IUserService
{
private IUserDataService _userDataService;
private IUserFormatingService _userFormatingService;

public UserService(IUserDataService userDataService,
IUserFormatingService userFormatingService)
{
this._userDataService = userDataService;
this._userFormatingService = userFormatingService;
}

#region IUserService Members

/// <summary>
/// Adds the specified user.
/// </summary>
/// <param name="user">The user.</param>
/// <returns>The user id</returns>
public int Add(User user)
{
if (user == null)
{
throw new ArgumentException("No se ha provisto un usuario");
}

//NOTE: Si propiedad Login es nula, habrá una
//      excepción no esperada.
if (user.Login.Length < 5)
{
throw
new ArgumentException("Login deber ser mayor a 5 caracteres.");
}

if (string.IsNullOrEmpty(user.Name))
{
throw new ArgumentException("Debe Proveer un Nombre.");
}

if (CalculateAge(user.BirthDate) < 18)
{
throw
new ArgumentException("Debe ser mayor de 18 años " +
" para poder registrarse.");
}

if (!_userDataService.IsLoginNameAvailable(user.Login))
{
throw new ArgumentException("Login no disponible");
}

if (!IsEmail(user.Email))
{
throw new ArgumentException("Email Inválido");
}

return _userDataService.AddToDB(user);
}

#endregion

Queremos asegurar que UserService funciona correctamente, pero para ello ocuparíamos las dependencias IUserDataService y IUserFormatingService, que por cierto aún no han sido implementadas y ni siquiera existe una base de datos. Es, en este punto donde entra Moq. Para ello creamos un proyecto y agregamos una clase UserServiceTest que tendrá los tests relacionados con UserService, para las dependencias creamos dos “mocks” con los cuales controlamos que le pasaremos a la clase y que nos está mandando ella.

El método GetUserForTest lo que hace es regresar un usuario válido el cual modificaremos según sea requerido en cada uno de los test. En el constructor inicializamos el servicio y proveemos los “mocks“.


[TestFixture]
public class UserServiceTest
{
private Mock<IUserDataService> _userDataService = new Mock<IUserDataService>();

private Mock<IUserFormatingService> _userFormatingService = new Mock<IUserFormatingService>();

private IUserService _userService;

public UserServiceTest()
{
_userService = new UserService
(_userDataService.Object, _userFormatingService.Object);
}

private User GetUserForTest()
{
User user = new User();
user.Login = "elvis";
user.Name = "David";
user.Password = "un_password_compliCAdo";
user.Email = "test@test.com";
user.Country = "Costa Rica";
user.SingUpDate = DateTime.Now;
user.BirthDate = new DateTime(1966, 06, 06);

return user;
}

[Test]
public void Add_User_Test()
{
User user = GetUserForTest();

_userDataService.Setup(x => x.IsLoginNameAvailable(user.Login)).
Returns(true);
_userDataService.Setup(x => x.AddToDB(user)).Returns(1);

try
{
int userId = _userService.Add(user);
Assert.AreEqual(1, userId);
}
catch (Exception)
{
Assert.Fail("No se esperaba ninguna excepción");
}
}

[Test]
[ExpectedException(typeof(ArgumentException))]
public void Add_User_Login_Short_Lenght()
{
User user = GetUserForTest();

user.Login = "zord";

_userDataService.Setup(x =>
x.IsLoginNameAvailable(It.IsAny<string>()))
.Returns(true);
_userDataService.Setup(x => x.AddToDB(user)).Returns(1);

try
{
int userId = _userService.Add(user);
Assert.Fail("Se esperaba una excepción");
}
catch (Exception)
{
throw;
}
}

[Test]
[ExpectedException(typeof(ArgumentException))]
public void Add_User_Login_Short_Lenght_BUG()
{
User user = GetUserForTest();
user.Login = null;
_userDataService.Setup(x =>
x.IsLoginNameAvailable(user.Login))
.Returns(true);

_userDataService.Setup(x => x.AddToDB(user)).Returns(1);

try
{
int userId = _userService.Add(user);
Assert.Fail("Se esperaba una excepción");
}
catch (Exception)
{
throw;
}
}
}

En Add_User_Test() y para cada test configuramos los “mocks” para establecer los comportamientos requeridos, así por ejemplo UserService.Add(User) utiliza de IUserDataService los métodos IsLoginNameAvailable que recibe un string y regresa un booleano y AddToDB que recibe un User y regresa un entero, el cual es el ID asignado. Para la configuración llamamos el método Setup del moq. Note que en la expresión lambda decimos que de “x” vamos a configurar el método IsLoginNameAvailable he indicamos que esperamos en sus parámetros, cuando reciba user.login, se refiere al valor exacto que contenga al momento de la configuración, si el valor no interesa como en Add_User_Login_Short_Lenght usamos un “wildcard” que indica que cualquier valor string es válido => It.IsAny(), y finalmente con Returns indicamos que siempre que se cumplan las condiciones retornaremos True.

   1: _userDataService.Setup(x => x.IsLoginNameAvailable(user.Login)).Returns(true);

Lo mismo sucede con AddToDB que retornará el id 1 siempre que sea invocada con la instancia “user”

   2: _userDataService.Setup(x => x.AddToDB(user)).Returns(1);

Finalmente implementamos los Asserts de NUnit para asegurar los valores.

Un BUG

El método Add_User_Login_Short_Lenght_BUG intencionalmente contiene un bug, ya que está diseñado para fallar cuando cuando la longitud de la propiedad LoginName es vacía o menor a 5, en cuyo caso se producirá una excepción tipo ArgumentException. Sin embargo la propiedad está nula y al intentar accederla se produce System.NullReferenceException lo cual no es un comportamiento esperado y por tanto un BUG del sistema.

Lo primero que debemos hacer al encontrar un bug, antes de arreglarlo es crearle un test, luego corregirlo y de esta manera queda asegurado que si el bug vuelve a aparecer existirá un prueba que nos va decir con anterioridad de la existencia del problema.

Gran parte de la idea de tener pruebas es que nos estén asegurando que el sistema está funcionando correctamente y que los cambios que vamos introduciendo no lo están quebrando. Si logramos tomar nuestro sistema por unidades y atomizar cada una de las pruebas aseguramos que si cada una funciona como debe en forma individual deben funcionar de manera conjunta y de no ser así, implica que alguna de las partes está fallando y las pruebas no son correctas o no son las suficientes.

Más Moq

Algunas otras cosas que podemos hacer con moq.

Parámetros

Accesando los parámetros con los cuales se hizo el llamado para el retorno.

   1: _userDataService.Setup(x => x.AddID(It.IsAny()))

   2: .Returns((string login) => string.Format("{0}ID", login));

CallBacks

En la línea 2 se llama el callback antes de la invocación del return y se accesa el argumento miertras en la línea 3 se invoca despues del return

   1: _userDataService.Setup(x => x.AddToDB(It.IsAny()))

   2: .Callback((User inserUser) =>

   3:   Console.WriteLine(string.Format("Adding user {0}", inserUser.Login)))

   4: .Returns(1)

   5: .Callback(()=> Console.WriteLine("User Inserted"));

Excepciones

Moq puede configurar excepciones según la condición

   1: _userDataService.Setup(x => x.IsLoginNameAvailable(null))

   2: .Throws(new ArgumentException("Valor no puede ser nulo"))

Matching

Como en el ejemplo se pueden usar “Matchings” que indiquen los valores esperados.

Indicar que espera cualquier objeto de tipo User

   1: _userDataService.Setup(x => x.AddToDB(It.IsAny())).Returns(1);

Valida los valores que cumplan con el predicado dado, ósea el valor esperado deber ser string y deber ser igual a “test”

   1: _userDataService.Setup(x => x.IsLoginNameAvailable(It.Is<string>(l => l.Equals("Test"))))

   2: .Returns(true);

Expresiones Regulares

   1: _userDataService.Setup(x =>

   2: x.IsLoginNameAvailable(It.IsRegex(@"^([a-zA-Z0-9_\-\.]+)", RegexOptions.IgnoreCase)))

   3: .Returns(true);

Rangos, ejemplo si queremos usar un número entero que no sea ni el mínimo, ni el máximo

   1: moq.Setup(x =>

   2:  x.Ejemplo(It.IsInRange<int>(int.MinValue, int.MaxValue, Range.Exclusive)))

   3: .Return(true);

Son algunas pocas opciones del framework aun quedan eventos, propiedades, verificaciones, comportamientos, avanzados, etc. Ejemplos conceptuales los podemos encontrar en QuickStart de la pagina.

Inversión de Control e Inyección de dependencias

ihenrysmith — Sun, 14 Mar 2010 20:32:00 +0000

Inversión de control e inyección de dependencia son términos que se confunden constantemente, vale la pena aclarar desde el inicio que la inyección de dependencia es una forma de implementar la inversión de control, de la misma forma existen otras implementaciones con, por ejemplo, el patrón “Factory” o el “service locator”.

La característica principal de la inversión de control es que el control del flujo es invertido con respecto a los métodos tradicionales. En vez de tener un código central que lo controle, indicamos que es lo que estamos esperando, para que una entidad aparte se encargue de proveerlo, así, es esta entidad quien decide como y cuando proveer lo esperado. En pocas palabras, nuestro código es el llamado, y no como ocurre comúnmente, cuando nuestro código es quien tiene el control del flujo y lo que hace es hacer llamadas. Se dice que es una implementación del Principio de Hollywood “No llame, nosotros le llamamos”.

Para obtener flexibilidad, “testeabilidad” y reutilización, debemos buscar siempre el menor acoplamiento posible. Si hacemos este acoplamiento por medio de interfaces y utilizamos una entidad aparte para que nos provea la implementación concreta, nos simplificamos sobre manera cambios futuros, ya que solo deberíamos cambiar la implementación sin tener que modificar en lo absoluto el objeto dependiente.

Estando claros que la inyección de dependencia es una forma específica de implementar inversión de control. Podríamos decir que lo que haremos es “inyectar” los objetos necesarios, según una configuración previa, evitando que sea la misma clase quien se encargue de crearlos u obtenerlos, así nos desentendemos de manejar su implementación por completo, ósea, no nos preocupamos por su ciclo de vida del todo. Usualmente utilizaremos un contenedor que se encargue de todo lo referente a la inyección propiamente dicha (creación, inyección, dependencias, destrucción, etc), si este contenedor esta externo podríamos decir que estamos utilizando inversión de control.

Con una comprensión más clara de los conceptos, que de alguna forma, es muy posible ya estemos aplicando, estaremos en posibilidad de escribir código más desacoplado, flexible y sobre todo reutilizable.

Contenedor IoC

ihenrysmith — Sat, 13 Mar 2010 18:44:00 +0000

Cuando decidimos utilizar IoC (“Inversion of Control” – Inversión de Control) ocupamos un Contenedor o en otras palabras un software, en el cual podamos registrar nuestros objetos ya sea por medio de un archivo de configuración (usualmente XML) o desde el código mismo y que sea este quien se encargue de la inicialización de los objetos que estamos esperando. La idea es que podamos tomar ya sea una clase abstracta o una Interfase y pedirle al contenedor que nos resuelva la instancia concreta deacuerdo con la definición esperada. Steven Sanderson en su libro Pro ASP.NET MVCFramework (el cual les recomiendo) añade que un buen contenedor debe contar con tres características extra más allá de simplemente resolver la inicialización de la instancia.

Esta tres características son:

Resolución de dependencias en cadena: Lo que implica que si se esta resolviendo la dependencia de un objeto que requiere de otro, el contenedor debe ser capaz de proveer la dependencia requerida.
Tiempo de vida de los objetos: Debe encargarse de mantener el estilo de vida de los objetos. Si una instancia es solicitada más de una vez, el contenedor deberá escoger entre varias opciones, por ejemplo mantener una única instancia para todas las solicitudes (singleton), o crear una nueva por solicitud (transient), entre otras. Esto es lo que se conoce como el “lifestyle” del objeto, hay varias opciones predefinidas como singleton (que es la default), thread, transient, pooled y customizadas como PerWebRequest.
Valores de parámetros explícitos para los constructores: Esto quiere decir que si un constructor que debe inicializar el contenedor requiere de parámetros, deber existir un medio en la configuración que permita proveer los valores. El ejemplo clásico es el ConnectionString para el acceso a datos o el servidor SMTP para enviar correos.

Otra parte complicada es escoger cual de los contenedores disponibles actualmente vamos a usar. Entre los más comunes se encuentran:

Castle Windsor (El que usamos actualmente)
Spring.NET
StructureMap
Unity
Puzzle.NFactory

Después de una rápida vista por google, nos damos cuenta lo difícil que es escoger alguno, a Spring por ejemplo se le achaca la poca documentación y el echo que sea portado de Java. Muchos tienden a usar Castle Windsor por su documentación y se podría decir que es el más popular en este momento.

Hay que recordar que utilizar un Contenedor puede provocar un poco de “overhead“en la creación de los objetos, pero esto es compensado con todas la facilidades que su uso implica.

Again??

ihenrysmith — Mon, 01 Mar 2010 04:30:00 +0000

Parece que de verdad olvide esto :p….. pero en el futuro prometo meter algunas otras entras ….:p

El Génesis..

ihenrysmith — Fri, 12 Sep 2008 21:25:00 +0000

Conforme tenga tiempo espero poder publicar cosas de interés sobre tecnologías de programación relacionadas a los proyectos en que trabajo y demás pasatiempos personales… Cosas como Java, Javascript, C#, C++, SQL server, Pascal, entre otros….

Sin mas por el momento, me despido!