Esta nota viene a cerrar una serie de tres posts anteriores

TDD… y las cosas, felizmente, no volvieron a ser las mismas…,

TDD, por dónde empezar y

TDD, ahora Refactoring.

En este caso, a pedido de Luis Petek en un comentario al tercer post de la serie, explico algunos otros atributos de NUnit que podrían ser de utilidad.

Así como la rutina que esté marcada por el atributo <Setup> se ejecuta antes de cada uno de los Tests, existe una forma de marcar otra rutina para que se ejecute después de cada uno de los Test.

Este atributo es <TearDown>.

En el ejemplo que venimos siguiendo, vamos a desdoblar la declaración de la variable configurationAppSettings de su instancia, sólo con el fin de darle sentido al ejemplo.

Dejo la declaración donde está y su instancia pasa al setup.

C#

using NUnit.Core;

using NUnit.Framework;

 

[TestFixture()]

public class Class1

{

    public System.Configuration.AppSettingsReader configurationAppSettings;

    public string sKeyClave;

 

    [SetUp()]

    public void Setup()

    {

        configurationAppSettings = new System.Configuration.AppSettingsReader();

        sKeyClave = (string)(configurationAppSettings.GetValue(“Clave”, typeof(string)));

    }

 

    [Test()]

    public void Prueba()

    {

        Assert.IsNotNull(sKeyClave);

    }

 

    [TearDown]

    public void Dispose()

    {

        configurationAppSettings = null;

    }

 

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

 

<TestFixture()> _

Public Class Class1

    Public configurationAppSettings As System.Configuration.AppSettingsReader

    Public sKeyClave As String

 

    <SetUp()> _

    Public Sub Setup()

        configurationAppSettings = New System.Configuration.AppSettingsReader

        sKeyClave = CType(configurationAppSettings.GetValue(“Clave”, GetType(System.String)), String)

    End Sub

 

    <Test()> _

    Public Sub Prueba()

        Assert.IsNotNull(sKeyClave)

    End Sub

 

    <TearDown()> _

    Public Sub Dispose()

        configurationAppSettings = Nothing

    End Sub

End Class

 

Compilamos y ejecutamos un Testing:

¡Verde!…

Podemos continuar.

Cabe aclarar que, del mismo modo que con <Setup>, no puede haber más que un <TearDown> por TestFixture.

Existe también una forma de verificar la generación de una excepción, para nuestro ejemplo voy a plantear el caso de intentar recuperar una clave inexistente de app.config:

C#

using NUnit.Core;

using NUnit.Framework;

 

[TestFixture()]

public class Class1

{

    public System.Configuration.AppSettingsReader configurationAppSettings;

    public string sKeyClave;

 

    [SetUp()]

    public void Setup()

    {

        configurationAppSettings = new System.Configuration.AppSettingsReader();

        sKeyClave = (string)(configurationAppSettings.GetValue(“Clave”, typeof(string)));

    }

 

    [Test()]

    public void VerificarClave()

    {

        Assert.IsNotNull(sKeyClave);

    }

 

    [Test]

    [ExpectedException(typeof(System.InvalidOperationException))]

    public void EsperaUnaExcepcion()

    {

        sKeyClave = (string)(configurationAppSettings.GetValue(“NoExiste”, typeof(string)));

        Assert.IsNull(sKeyClave);

    }

 

    [TearDown]

    public void Dispose()

    {

        configurationAppSettings = null;

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

 

<TestFixture()> _

Public Class Class1

    Public configurationAppSettings As System.Configuration.AppSettingsReader

    Public sKeyClave As String

 

    <SetUp()> _

    Public Sub Setup()

        configurationAppSettings = New System.Configuration.AppSettingsReader

        sKeyClave = CType(configurationAppSettings.GetValue(“Clave”, GetType(System.String)), String)

    End Sub

 

    <Test()> _

    Public Sub VerificarClave()

        Assert.IsNotNull(sKeyClave)

    End Sub

 

    <Test(), ExpectedException(GetType(System.InvalidOperationException))> _

    Public Sub EsperaUnaExcepcion()

        sKeyClave = CType(configurationAppSettings.GetValue(“NoExiste”, GetType(System.String)), String)

        Assert.IsNull(sKeyClave)

    End Sub

 

    <TearDown()> _

    Public Sub Dispose()

        configurationAppSettings = Nothing

    End Sub

End Class

 

Además le modifiqué el nombre Prueba por VerificarClave para mayor claridad.

Compilemos y ejecutemos el Test:

¡Verde!…

Podemos ver que en EsperaUnaExcepcion el Test es exitoso cuando se produce la excepción, esto es porque al intentar recuperar la clave NoExiste de app.config se produce la excepción.

Si quieren verificar, cambien el string NoExiste por Clave, que si existe en app.config, y podrán ver que el Test EsperaUnaExcepcion falla.

Existen más atributos de NUnit, les recomiendo que lean la documentación, aquí tienen la lista completa de atributos y en este otro link pueden acceder a la documentación en general de NUnit para todas sus versiones.

Ojalá les sea útil y espero sus comentarios. :)

Este post es continuación y cierre de estos dos:

TDD… y las cosas, felizmente, no volvieron a ser las mismas…

TDD, ¿por dónde empezar?

De acuerdo a lo que expresé en los post anteriores, TDD se se lleva a cabo sobre ciclos. Al finalizar cada ciclo TDD, la técnica se completa con la práctica de Refactoring.

Refactoring es la aplicación de distintas técnicas que mejoran la calidad del código. Como en TDD, se recomienda realizar cambios pequeños, a fin de garantizar un tránsito entre estados deseables, en otras palabras, mantener la integridad de los Tests.

Refactoring, también se practica sobre ciclos.

El Cliclo de Refactoring lo podemos resumir en los siguientes pasos:

  • Identificar un problema,
  • Seleccionar la técnica de Refactoring a aplicar,
  • Realizar los cambios en el código,
  • Compilar,
  • Ejecutar los Tests.
  • Recomenzar

Los cambios en código operados por el Refactoring deben ser pequeños, esto garantiza la transición de una versión a otra de forma estable.

Vuelvo al código del ejemplo anterior. Repasemos la clase de la aplicación, Recupera, está encargada de recuperar un string:

C#

public class Recupera

{

    public string Valor()

    {

        return “Prueba”;

    }

}

 

VB

Public Class Recupera

    Public Function Valor() As String

        Return “Prueba”

    End Function

End Class

 

Voy a declarar la función Recupera como estática, de esa forma no va a ser necesario instanciarla para invocarla. Veamos como queda:

C#

public class Recupera

{

    public static string Valor()

    {

        return “Prueba”;

    }

}

 

VB

Public Class Recupera

    Public Shared Function Valor() As String

        Return “Prueba”

    End Function

End Class

 

Pero si vamos a nuestra clase de Test nos encontramos con un error. Es lógico, ya que estamos instanciando una clase estática y eso no es correcto.

C#

using NUnit.Core;

using NUnit.Framework;

using SyPCS;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

        [Test]

        public void Prueba()

        {

            Recupera recupera = new Recupera();

            string s = recupera.Valor();

            Assert.IsNotNull(s);

        }

    }

}

VB

Imports NUnit.Core

Imports NUnit.Framework

Imports SyPVB

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

        <Test()> _

        Public Sub Prueba()

            Dim mRecupera As New Recupera

            Dim s As String = mRecupera.Valor

            Assert.IsNotNull(s)

        End Sub

    End Class

End Namespace

 

Practicamos el Refactoring correspondiente y obtenemos

C#

using NUnit.Core;

using NUnit.Framework;

using SyPCS;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

        [Test]

        public void Prueba()

        {

            Assert.IsNotNull(Recupera.Valor());

        }

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

Imports SyPVB

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

        <Test()> _

        Public Sub Prueba()

            Assert.IsNotNull(Recupera.Valor)

        End Sub

    End Class

End Namespace

 

Se lee un código más sintético, evitamos la declaración de ’s’, que, todos sabemos, es un nombre horrible.

Hagamos un Build, <Ctrl>/<Shift>/<B> y vamos a NUnit, encotramos todos los indicadores en gris, porque hicimos un build.

Ejecutamos y…

¡Verde!

Seguimos adelante.

Ahora vamos por un Refactoring que modifique Recupera de tal forma que extraiga el valor de un lugar un poco más serio, por ejemplo de un archivo de configuración, en este caso app.config como el siguiente:

<?xml version=1.0 encoding=utf-8 ?>

<configuration>

  <appSettings>

    <add key=Clave value=Prueba/>

  </appSettings>

</configuration>

 

Dentro de configuration, en el bloque appSettings agregamos una entrada que identificamos como ‘Clave’ con el valor que querramos recuperar, en este caso ‘Prueba’.

Las clases de Testing quedarían así:

C#

using NUnit.Core;

using NUnit.Framework;

using SyPCS;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

        System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader();

 

        [Test]

        public void Prueba()

        {

            Assert.IsNotNull(configurationAppSettings.GetValue(“Clave”, typeof(string)));

        }

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

Imports SyPVB

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

        Public configurationAppSettings As New System.Configuration.AppSettingsReader

 

        <Test()> _

        Public Sub Prueba()

            Assert.IsNotNull(configurationAppSettings.GetValue(“Clave”, GetType(System.String)))

        End Sub

    End Class

End Namespace

 

Compilamos, no da errores, entonces hacemos un Test:

¡Verde!… A Recomenzar…

Si miramos las clases de Testing podremos ver que la referencia al proyecto SyPCS, en C#, y SyPVB, en VB, ya no son necesarios. Nuestro próximo ciclo se trata de eliminar esas referencias y su Namespace correspondiente.

Esto tiene un doble beneficio, independiza el proyecto de Testing del proyecto de desarrollo y como consecuencia resulta un código más claro de leer.

C#

using NUnit.Core;

using NUnit.Framework;

 

[TestFixture]

public class Class1

{

    System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader();

 

    [Test]

    public void Prueba()

    {

        Assert.IsNotNull(configurationAppSettings.GetValue(“Clave”, typeof(string)));

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

 

<TestFixture()> _

Public Class Class1

    Public configurationAppSettings As New System.Configuration.AppSettingsReader

 

    <Test()> _

    Public Sub Prueba()

        Assert.IsNotNull(configurationAppSettings.GetValue(“Clave”, GetType(System.String)))

    End Sub

End Class

 

Nuevamente compilamos y ejecutamos Testing:

¡Verde!…

Podemos dar por concluido nuestro Refactoring e incorporar la llamada al archivo de configuración al proyecto de desarrollo con la seguridad que el mismo funciona. Primero creamos en cada uno de ellos un archivo de configuración como los que creamos en los proyectos de Testing y luego hacemos el reemplazo:

C#

public class Recupera

{

    public static string Valor()

    {

        System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader();

        return ((string)(configurationAppSettings.GetValue(“Clave”, typeof(string))));

    }

}

 

VB

Public Class Recupera

    Public Shared Function Valor() As String

        Dim configurationAppSettings As New System.Configuration.AppSettingsReader

        Return CType(configurationAppSettings.GetValue(“Clave”, GetType(System.String)), String)

    End Function

End Class

 

Un último detalle en nuestros proyectos de Testing.

Podemos pensar en que el valor levantado del archivo de configuración se va a utilizar en otros Test que van a irse desarrollando, entonces podemos pensar que es ineficiente que en cada Test que se ejecute, se esté recuperando exactamente el mismo valor.

Para este tipo de situaciones existe el tag <Setup> en NUnit. Este tag indica a NUnit que la rutina que clasifica es común a todos los Tests que encierra la clase.

Veamos cómo quedan nuestros ejemplos:

C#

using NUnit.Core;

using NUnit.Framework;

 

[TestFixture()]

public class Class1

{

    public System.Configuration.AppSettingsReader configurationAppSettings = new System.Configuration.AppSettingsReader();

    public string sKeyClave;

 

    [SetUp()]

    public void Setup()

    {

        sKeyClave = (string)(configurationAppSettings.GetValue(“Clave”, typeof(string)));

    }

 

    [Test()]

    public void Prueba()

    {

        Assert.IsNotNull(sKeyClave);

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

 

<TestFixture()> _

Public Class Class1

    Public configurationAppSettings As New System.Configuration.AppSettingsReader

    Public sKeyClave As String

 

    <SetUp()> _

    Public Sub Setup()

        sKeyClave = CType(configurationAppSettings.GetValue(“Clave”, GetType(System.String)), String)

    End Sub

 

    <Test()> _

    Public Sub Prueba()

        Assert.IsNotNull(sKeyClave)

    End Sub

End Class

 

Y con esto estamos en condiciones de seguir practicando TDD.

Cierro este post agradeciendo los comentarios elogiosos y el aliento que me brindaron comentando en este blog y en el grupo CodeGeneration de Google a Ángel “Java” López, Martín Salías, Luis Petek y Luis Lobo Borobia. :)

Este post es continuación de este otro.

Supongamos que tenemos una aplicación que necesita recuperar una cadena. El Test que acá vamos a desarrollar es probar la recuperación de esta cadena.

Ya tendríamos que tener instalada la última versión de NUnit. Sino, podemos descargarla desde http://www.nunit.org e instalarla.

En el marco de nuestra solución vamos a agregar un proyecto de tipo Class Library donde iremos escribiendo el Test. El ejemplo lo desarrollo en Visual Basic .NET y C#.

Una característica curiosa de esta técnica es que estos proyectos no se ejecutan, sólo se compilan y la dll resultante es la que se prueba con la herramienta.

En el proyecto de test hay que agregar las referencias que exige NUnit, buscamos en la carpeta bin de la instalación de NUnit, tipicamente C:\Program Files\NUnit 2.4.6\bin dependiendo de la versión de la heramienta. Estas referencias son nunit.core y nunit.framework.

VB

En C# hay que agregar una referencia más, nunit.core.interfaces.dll

Para definir una clase básica para comenzar a practicar TDD veamos estos ejemplos:

C#

using nunit.core;

using nunit.framework;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

 

    }

}

VB

Imports NUnit.Core

Imports NUnit.Framework

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

 

    End Class

End Namespace

Tenemos dos elementos novedosos. En primer lugar tenemos que importar las dlls de NUnit que posibilitan el trabajo con la herramienta y en segundo lugar el tag TestFixture que posibilita que NUnit reconozca a la clase como contenedore de Tests.

Compilemos esto.

Ya tenemos la base para programar nuestro primer Test.

Nuestra aplicación tiene que ser capaz de leer un valor que se recupera desde algún elemento de persistencia. De esto se tratará nuestro Test.

Entonces, siguiendo con el esquema de Ciclo TDD que presenté en el post anterior,

  • Escribir un Test, aún de algo que todavía no hayamos codificado,
  • Compilar, va a dar error, ya que todavía no hemos codificado lo que estamos probando,
  • Escribir la mínima cantidad de código para que compile, aunque sea la cabecera del método o función a probar,
  • Compilar, ahora no da error, estamos en condiciones de ejecutar nuestro Test,
  • Ejecutar el Test, falla, ya que habíamos escrito la mínima cantidad de código que garantice la compilación, pero no la ejecución del Test,
  • Escribir la mínima cantidad de código para que el Test no falle,
  • Ejecutar el Test, esta vez no falla,
  • Refactorizar, este es un tema aparte, hay variadas técnicas de refactorización y muchos buenos libros escritos, más adelante veremos someramente alguna de esas técnicas,
  • Recomenzar escribiendo un nuevo Test.

Comienzo por Escribir un Test, aún de algo que todavía no hayamos codificado:

C#

using NUnit.Core;

using NUnit.Framework;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

        [Test]

        public void Prueba

        {

            Recupera recupera = new Recupera;

            Assert.IsNotNull(recupera.Valor);

        }

    }

}

VB

Imports NUnit.Core

Imports NUnit.Framework

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

        <Test()> _

        Public Sub Prueba()

            Dim mRecupera As New Recupera

            Assert.IsNotNull(mRecupera.Valor)

        End Sub

    End Class

End Namespace

Si. Ya sé…

Yo también me indigné la primera vez que vi algo como esto…

Obviamente… no compila…

No hay nada declarado con el nombre Recupera y menos su propiedad Valor.

Pero esta es la idea.

El segundo paso es Compilar.

Y falla, como se lee en el ciclo TDD.

Ahora tenemos que Escribir la mínima cantidad de código para que compile

Entonces voy a crear dos proyectos, uno C# y otro VB, ambos de tipo Class Library (para hacerlo más simple) que jugarán el papel de proyectos de desarrollo.

En ambos codificamos una función de nombre Valor.

C#

public class Recupera

{

    public void Valor()

    {

 

    }

}

VB

Public Class Recupera

    Public Function Valor()

 

    End Function

End Class

Compilamos ambos proyectos.

Ahora vamos a los proyectos de Testing, en cada uno de ellos agregamos una referencia, en TestCS agregamos la referencia a SyPCS y en TestVB agregamos una a SyPVB.

De esa forma podemos adicionar al código el using (en C#) o Imports (en VB) que corresponda.

Quedando así:

C#

using NUnit.Core;

using NUnit.Framework;

using SyPCS;

 

namespace SyPCS.Test

{

    [TestFixture]

    public class Class1

    {

        [Test]

        public void Prueba()

        {

            Recupera recupera = new Recupera();

            string s = recupera.Valor();

            Assert.IsNotNull(s);

        }

    }

}

 

VB

Imports NUnit.Core

Imports NUnit.Framework

Imports SyPVB

 

Namespace SyPVB.Test

    <TestFixture()> _

    Public Class Class1

        <Test()> _

        Public Sub Prueba()

            Dim mRecupera As New Recupera

            Dim s As String = mRecupera.Valor

            Assert.IsNotNull(s)

        End Sub

    End Class

End Namespace

Según el ciclo, nuestro próximo paso es Compilar.

Y compila. Estamos en condiciones de ejecutar nuestro primer Test.

Abrimos NUnit y vemos su IDE:

Vamos a File/New Project y le ponemos el nombre Ejemplo:

Ahora vamos a Project/Add assembly… y seleccionamos la dll de alguno de los proyectos de Testing, por ejemplo el de VB:

y veremos lo siguiente:

Vemos que el árbol de Test se ve en el Gris de Refactoring.

Siguiendo en el Cliclo TDD ejecutamos el Test. Hacemos Click sobre el botón Run en NUnit y …

¡Falló!…

Tal como dicta el Ciclo TDD.

Sigamos con Escribir la mínima cantidad de código para que el Test no falle.

Hacemos que nuestra función Valor devuelva un string cualquiera:

C#

public class Recupera

{

    public string Valor()

    {

        return “Prueba”;

    }

}

 

VB

Public Class Recupera

    Public Function Valor() As String

        Return “Prueba”

    End Function

End Class

Y volvemos a compilar los cuatro proyectos, primero los de Desarrollo, luego los de Prueba.

Volvemos a NUnit y vemos todo en Gris nuevamente:

Y ahora hacemos click nuevamente en Run y …

¡¡¡Green!!!

Anduvo. Según el Ciclo TDD nos toca Refactorizar.

Pero esto… en el próximo post. :)

TDD, Test Driven Development, es una técnica que establece que primero se escriben las pruebas y luego el código del aplicativo.

Estas pruebas se efectúan de acuerdo a lo que se espera que haga el aplicativo, es por eso que algunos popes de esta disciplina dicen que practicándola intensivamente podemos prescindir de la documentación ya que el código de las pruebas es en si mismo documentación acerca del aplicativo.

En otras palabras las pruebas especifican lo que se espera de la aplicación a desarrollar.

Esta práctica es de amplia difusión en las Metodologías Ágiles, con esto se garantiza código de calidad desde el inicio del proceso de desarrollo y proporciona un buen elemento para el establecimiento de métricas.

El Ciclo TDD se compone de los siguientes pasos:

  • Escribir un test, aún de algo que todavía no hayamos codificado,
  • Compilar, va a dar error, ya que todavía no hemos codificado lo que estamos probando,
  • Escribir la mínima cantidad de código para que compile, aunque sea la cabecera del método o función a probar,
  • Compilar, ahora no da error, estamos en condiciones de ejecutar nuestro Test,
  • Ejecutar el test, falla, ya que habíamos escrito la mínima cantidad de código que garantice la compilación, pero no la ejecución del Test,
  • Escribir la mínima cantidad de código para que el Test no falle,
  • Ejecutar el test, esta vez no falla,
  • Refactorizar, este es un tema aparte, hay variadas técnicas de refactorización y muchos buenos libros escritos, más adelante veremos someramente alguna de esas técnicas,
  • Recomenzar escribiendo un nuevo Test.

Es habitual encontrar TDD asociado a estas tres palabras en sus respectivos colores:

Red, Green, Refactor

Estos son términos y colores asociados a la familia de herramientas de Test Unitarios xUnit, dela que usaremos NUnit, se pueden descargar la última versión desde http://www.nunit.org, también van a encontrar documentación.

Red, está asociado a la ejecución fallida de uno o más Tests.

Green, es el color que se ve en la IDE de NUnit al ejecutar exitosamente uno o más Test.

Refactor, lo podemos ver cuando estamos refactorizando nuestro proyecto de Testing.

Es muy importante que las modificaciones se hagan en pequeños pasos, esto hace a la estabilidad del código probado a lo largo del proceso de desarrollo. Una buena estrategia de Testing evita los grandes objetos, los Test integrales, la interdependencia entre las pruebas.

Una buena estructura TDD tiende a que el equipo de desarrollo esté más y mejor comunicado. Como se elimina la probabilidad de romper funcionalidad existente al liberar código nuevo, se eliminan temores a “papelones”.

La Barra Verde que nos muestra NUnit cuando los Test son exitosos se convierten en un factor motivacional positivo.

Por su propia naturaleza, TDD elimina los problemas derivados de las contínuas postergaciones del Debugging.

¿Y?… ¿cómo se hace?…

Te pido que me esperes a que termine el próximo post. :)

Otra vez acá.

Basado en el ejemplo del post anterior, voy a introducir modificaciones al modelo original con la idea de ver que tan fácil es hacerlo y regenerar código.

Partimos entonces de la solución generada que pueden descargar desde acá.

Supongamos que ahora nos piden que incluyamos un campo Telefono para la tabla Sucursal.

Conviene agregar algunos registros en las tablas para facilitar la prueba.En primer lugar abrimos SQL Server Management Studio, buscamos en la base de datos Prueba y en la tabla Sucursal agregamos un campo Telefono de tipo VARCHAR(50), grabamos los cambios.

Luego abrimos nuestro modelo con el Modeler y pulsamos Refresh. Al desplegar Sucursal veremos lo siguiente: 

Ahora hacemos click sobre Quick generation, al finalizar abrimos la solución con Visual Studio y ejecutamos.Podremos ver que la grilla ya contiene la columna Telefono y si cargaron algunos registros correctamente en las tablas, podrán ver los valores.

Seguimos pensando en otro tipo de modificación, por ejemplo una Asociación, supongamos que nos piden poder calificar las Sucursales por Provincia. Esto nos obliga a crear una tabla Provincia con un campo ID (PK, autonumérico e INT) y Descripcion (VARCHAR(50)). Para vincularla a la tabla Sucursal, agregamos en esta última un campo IDProvincia (FK e INT) luego establecemos la relación entre la PK de Provincia con la FK de Sucursal.

Hacemos un Refresh desde el Modeler,

Desplegamos Sucursal, chequeamos ProvinciaString y quitamos el check de ProvinciaEntity, click en Save model,

Ahora un Quick Generation y volvemos a la solución.

Veremos que se han producido una serie de erroes.

Para solucionarlo iremos primero al proyecto PruebaEntities, en la carpeta Objects agregamos la clase ProvinciaObject.vb y en la carpeta Object/Auto la clase ProvinciaObject.Auto.vb.

Luego en el proyecto PruebaData en la carpeta Gateways agregamos a ProvinciaGateway.vb y en Gateways/Auto la clase ProvinciaGateway.Auto.vb.

Finalmente en la carpeta Mappers la clase ProvinciaMapper.vb y en Mappers/Auto la clase ProvinciaMapper.Auto.vb

Si ejecutamos la solución, vamos a ver la columna Provincia incorporada a la grilla.

Supongamos que nos indican que cada Sucursal está asociada a un Depósito y cada una tiene uno propio. Podemos suponer esto como una Agregación, una relación uno a uno.

Importante: Tengamos en cuenta que para que una relación quede establecida como uno a uno en una base de datos, la PK y la FK deben ser exactamente iguales, mismos campos, mismos tipos, mismos nombres.

En nuestro ejemplo la PK de Sucursal la forman los campos ID e IDCliente (podría haber sido ID solamente) entonces vamos crear una tabla Deposito con estos dos campos un ID (PK, autonumérico, INT)y un campo Descripcion (VARCHAR(50)).

Luego debemos crear una relación uno a uno entre Sucursal y Deposito.

Volvemos al Modeler y hacemos un Refresh. Desplegamos Sucursal y vemos un nuevo elemento llamado DepositoAggregation, si intentamos chequearlo vamos a ver que en pocos segundos pierde el check. Esto sucede porque todavía no definimos su dependencia. Para eso hacemos click sobre el elemento Deposito, en la propiedad GenerateAsChildOf seleccionamos Sucursal. Ahora si podemos chequear sobre el elemento DepositoAggregation de Sucursal.

 

Ahora vamos a mirar el elemento Cliente, lo desplegamos y seleccionamos SucursalCollection, si vemos su propiedad GenerateAsType vale ObjectList, esto significa que la entidad Cliente, trae una colección de objetos. Como antes les conté, los objetos mapean uno a uno con las tablas de la base de datos, esto quiere decir que la agregación que recién incorporamos no es accesible desde la entidad Cliente.

Para que esto suceda hay que fijar la propiedad GenerateAsType de SucursalCollection con valor EntityList en la entidad Cliente.

 

Volvemos a hacer un Quick generation y abrimos la solución.

Vamos al proyecto PruebaEntities, en la carpeta Objects agregamos la clase DepositoObject.vb y en la carpeta Object/Auto la clase DepositoObject.Auto.vb.  En la carpeta Entities agregamos la clase Deposito.vb y en la carpeta Entities/Auto la clase Deposito.Auto.vb

Luego en el proyecto PruebaData en la carpeta Gateways agregamos a DepositoGateway.vb y en Gateways/Auto la clase DepositoGateway.Auto.vb.

Finalmente en la carpeta Mappers la clase DepositoMapper.vb y en Mappers/Auto la clase DepositoMapper.Auto.vb

Si todo esto fue bien todavía nos va a quedar un error en la lista:

Value of type ‘PruebaRules.Entities.SucursalList’ cannot be converted to ‘PruebaRules.Objects.SucursalObjectList’.   

Esto es en el método CargarGrillaSucursal del fromulario Form1. La linea que muestra el error es la siguiente:

Dim mSucursalList As SucursalObjectList = SucursalMapper.Instance.GetByCliente(CType(cboCliente.SelectedValue, Integer))

Esto es poruqe a la collección de Sucursales contenida en la entidad Cliente la cambiamos de ObjectList a EntityList. Corregida queda:

Dim mSucursalList As SucursalList = SucursalMapper.Instance.GetByCliente(CType(cboCliente.SelectedValue, Integer))

Cambiamos los tipos SucursalObjectList por tipos SucursalList.

Ahora tenemos un error en la siguiente linea:

Dim mSucursalListView As SucursalObjectListView = New SucursalObjectListView(mSucursalList)

Corregida queda:

Dim mSucursalListView As SucursalListView = New SucursalListView(mSucursalList)

Y esto es todo. Cuando lo ejecutemos en la grilla no vamos a ver automáticamente los campos de la agregación, pero van a notar que la agregacion ya es accesible.

Para terminar con esto incorporamos una Composición. Por ejemplo, nos cuentan que vamos a tener una lista de Contactos por cada Sucursal. Ya nos estamos imaginando una tabla Contacto con ID (PK, autonumérico, INT), IDSucursal (FK, INT), NombreApellido (VARCHAR(50)) y antes de establecer la relación entre Sucursal y Contacto, creamos un índice IsUnique sobre la columna ID

 

Ahora si podemos establecer la relación entre Contacto y Sucursal:

Volvemos una vez más al Modeler y hacemos Refresh.

Desplegamos Sucursal y vemos el nuevo elemento llamado ContactoCollection.

 

Antes de chequear ContactoCollection, debemos ir a la entidad Contacto a la propiedad GenerateAsChildOf la fijamos en el valor Sucursal. Ahora si, en la entidad Sucursal, chequemos ContactoCollection

 

Última vuelta al Modeler, Refresh y Quick generation, volvemos a la solución.

Vamos al proyecto PruebaEntities, en la carpeta Objects agregamos la clase ContactoObject.vb y en la carpeta Object/Auto la clase ContactoObject.Auto.vb.

Luego en el proyecto PruebaData en la carpeta Gateways agregamos a ContactoGateway.vb y en Gateways/Auto la clase ContactoGateway.Auto.vb.

Finalmente en la carpeta Mappers la clase ContactoMapper.vb y en Mappers/Auto la clase ContactoMapper.Auto.vb

Una vez hecho esto podemos acceder a un Contacto a través de la entidad Cliente, por ejemplo:

        Dim mCliente As Cliente = ClienteMapper.Instance.GetOne(1)

        mCliente.SucursalCollection.Item(2).ContactoCollection.Item(3).NombreApellido.Trim()

En la primera linea recuperamos el Cliente con ID igual a 1, en la segunda linea obtenemos el Nombre y Apellido del cuarto Contacto de la tercera Sucursal.

Repasando, con estos cuatro ejemplos que les presento vimos que las tablas pueden relacionarse de tres formas distintas en Cooperator, estas son:

  • Asociación, en el Modeler se ve como xxxxEntity, representa una relación que califica a la entidad base, en nuestro ejemplo, Sucursal Provincia.
  • Composición, en el Modeler se ve como xxxxCollection, es una relación 1 a n, hay que definir que la entidad colección sea definida como hija de la entidad base por medio de la propiedad GenerateAsChildOf.
  • Agregación, en el Modeler se ve como xxxxAggregate, es una relación 1 a 1 (las PK y FK deben se exactamente iguales), hay que definir que la entidad agregación sea definida como hija de la entidad base por medio de la propiedad GenerateAsChildOf.

Ýa en el estribo, tengamos en cuenta que, eL Mapper graba la Entidad con todas sus Composiciones y Agregaciones, no así con sus Asociaciones. Si el ID de la Asociación, no existe el motor SQL devuelve un error de integridad.

Acá les dejo el script de la base de datos resultante, el archivo Cooperator y el código generado para que jueguen.

Ojalá les sea útil   :)

Para quien no conoce nada acerca de Cooperator Framework le recomiendo leer mi post anterior Introducción a Cooperator Framework.

Comencemos por descargar la herramienta, aquí encontramos el último release de Cooperator Modeler, al finalizar la descarga, descomprimimos el archivo y podremos ver el ejecutable de nombre CooperatorModeler.exe, con un doble click veremos lo su interfaz gráfica:

 

La prueba la vamos a realizar sobre SQL Server 2005, entonces vamos a abrir SQL Server Management Studio y creamos una base de datos de nombre Prueba, donde crearemos dos tablas, Cliente y Sucursal con una relación 1 a n.

La tabla Cliente tiene un campo ID (PK, INT y autonumérico) y RazonSocial (VARCHAR(50)).

La tabla Sucursal tiene un campo ID (PK, INT y autonumérico), IDCliente (FK, INT y autonumérico) y Denominacion (VARCHAR(50)).

 

 

Establecemos la relación entre la PK de Cliente y la FK de Sucursal.

 

Volvamos ahora al Modeler y hagamos un click sobre el botón New Model, cuando se abra el formulario hacemos click sobre el botón Get Databases, seleccionamos la nuestra y Ok:

 

Ahora veremos el Modelo:

 

Desplegamos las Entidades:

 

Vemos que Cliente tiene una colección de Sucursales, pero si la queremos incluir en el modelo es necesario chequearla.

 

Seleccionemos ahora Sucursal:

Podemos ver la propiedad GenerateAsChildOf con el valor Cliente, si esto no fuera así, antes no hubieramos podido seleccionar, en Cliente, la colección de Sucursales. También vemos que en Sucursal existe una ClienteEntity, si se chequea esto la entidad Sucursal incuirá la entidad Cliente (padre) con todas sus propiedades, incluirla o no es una desición de diseño.

El elemento ClienteString va a mostrar el campo de la tabla Cliente que nosotros determinemos, seleccionemos el elemento RazonSocial de la tabla Cliente, la propiedad GenerateAsDescriptionField vale True, esto define que RazonSocial es el campo que se mostrará cuando se invoque Sucursal.ClienteString.

Un punto muy importante que resuelve Cooperator es la aplicación del patrón LazyLoad y lo hace sin ningún esfuerzo extra de nuestra parte. Seleccionemos el elemento SucursalCollection de la entidad Cliente, vemos que la propiedad GenerateAsLazyLoad está en True, no hace falta nada más.

Supongamos que nuestro Modelo, por ahora termina acá, lo salvamos y hacemos un click sobre Code Generation

 

Hacemos un click sobre Generate SP, al finalizar otro click sobre Generate source code y cuando finalice seleccionamos una carpeta en la que querramos generar nuestra solución y luego un click sobre Generate Solution (para esta primera vez).

Modeler casi inmediatamente nos va a avisar que la solución se generó exitosamente y nos preguntará si queremos abrirla, le contestamos que si y vamos al Visual Studio que se está abriendo.

 

Abramos el formulario en modo diseño y agreguemos un ComboBox de nombre cboCliente y un DataGridView de nombre dtgSucursal.

Para hacer la prueba vamos a cargar a mano algunos registros en las tablas.

Ahora vamos a agregar código al formulario Form1, comenzando por los Imports:

 

Imports PruebaRules.Entities

Imports PruebaRules.Objects

Imports PruebaRules.Mappers

Imports PruebaRules.Views

 

En el evento Load del formulario disparamos CargarComboCliente

    Private Sub CargarComboCliente()

        Dim mClienteList As ClienteList = ClienteMapper.Instance.GetAll()

        Dim mClienteListView As ClienteListView = New ClienteListView(mClienteList)

 

        cboCliente.DisplayMember = “RazonSocial”

        cboCliente.ValueMember = “ID”

 

        Dim mCliente As New Cliente

        mCliente.RazonSocial = “(Ninguno)”

        mClienteListView.Add(mCliente)

 

        mClienteListView.Sort(“RazonSocial”, True)

 

        cboCliente.DataSource = mClienteListView

 

        cboCliente.SelectedIndex = 0

    End Sub

Los Clientes se recuperan en un objeto ClienteList a través de su correspondiente Mapper,  en la segunda linea asigno este ClienteList a otro objeto ClienteListView que me permite más versatilidad. La tercer y cuarta linea de código me permiten definir que valores se van a ver en el ComboBox y cuales voy a recuperar al seleccionar un Cliente por medio de las propiedades DisplayMember y ValueMember respectivamente. En las siguientes tres lineas creo un objeto Cliente, le asigno el valor (Ninguno) y lo agrego en el ComboBox. Luego ordeno el objeto de tipo ClienteListView por medio de un Sort, le asigno dicho ListView a la propiedad DataSource del ComboBox y finalmente me posiciono en el valor (Ninguno) del ComboBox.

En el SelectedIndexChanged del ComboBox de Clientes disparo CargarGrillaSucursal:

    Private Sub CargarGrillaSucursal()

        Dim mSucursalList As SucursalObjectList = SucursalMapper.Instance.GetByCliente(CType(cboCliente.SelectedValue, Integer))

        Dim mSucursalListView As SucursalObjectListView = New SucursalObjectListView(mSucursalList)

        dtgSucursal.DataSource = mSucursalListView

    End Sub

Acá  usamos un objeto de tipo SucursalObjectList para obtener, por medio de su Mapper, la lista de Sucursales correspondiente al Cliente seleccionado en el ComboBox. Vemos que se usa un objeto de tipo SucursalObjectList y no uno de tipo SucursalList. Si vamos al Modeler y vemos el elemento SucursalCollection, tiene una propiedad de nombre GenerateAsType con valor ObjectList, si en esta propiedad seleccionamos el valor EntityList, podríamos haber usado un objeto de tipo SucursalList a cambio de SucursalObjectList.

A esta altura es necesario aclarar que un Object mapea uno a uno contra una tabla de la base de datos, mientras que en un objeto de tipo Entity no necesariamente es así.

Ahora F5 y a ver como anda.

No intenten hacer esto solos en sus casas.

Voy a subir el código de este post ya que va a ser la base de otros posteriores.

Prueba.coop es el archivo con que el Modeler persiste la información.

Script.sql, para crear la base de datos.

Prueba.zip la solución Visual Studio 2005

Espero les sirva y espero sus comentarios. :)

Este post es continuación de este anterior sobre Delegates. Si ya conocés el tema no te va a hacer falta empezar por él.

En .NET tenemos la posibilidad de publicar un evento, al cual uno o más objetos pueden suscribirse.

Cuando se produce el evento, el aplicativo informa a los objetos suscriptos, que en el entorno del evento ejecutarán el código que contengan en la definición de su clase.

Al producirse el evento se invoca un método definido por medio de un delegado

Este Delegate debe recibir dos parámetros de entrada, el primero de tipo Object que recibe el objeto que produce el evento, el segundo es algún objeto que derive de la clase EventArgs.

Vamos a ver un ejemplo con el que jamás podremos a llamar la atención de nadie que nos interese. :)

Desde este link pueden descargarlo.

Vamos a tener tres formularios, el primero de ellos tiene un TrackBar que cuando se modifica los otros dos formularios se “enteran” y muestran la modificación a través de un textBox.

El primer punto interesante es que no tengo que agregar nada de código en los formularios que se “enteran” del evento. En el ejemplo que les dejo, en VB.NET y C#, podemos ver que en los Form2 y Form3 sólo hay estructura para verse como formularios y para soportar un textBox.

Empiezo por la clase TrackBarChangeEventsArgs que encapsula el valor que toma el TrackBar cuando se modifica su estado.

[VB]

Imports System

 

”’ <summary>

”’ Encapsula el argumento del evento, en este caso es un entero

”’ que representa al valor del TrackBar.

”’ </summary>

”’ <remarks>La clase hereda de EventArgs.</remarks>

Class TrackBarChangeEventsArgs

    Inherits EventArgs

 

    Private mChange As Integer

 

    ”’ <summary>

    ”’ Constructor

    ”’ </summary>

    ”’ <param name=”pChange”>Valor del TrackBar.</param>

    ”’ <remarks></remarks>

    Public Sub New(ByVal pChange As Integer)

        MyBase.New()

        Me.mChange = pChange

    End Sub

 

    ”’ <summary>

    ”’ Publica el valor del argumento del evento, en este caso

    ”’ el valor del TrackBar.

    ”’ </summary>

    ”’ <value></value>

    ”’ <returns>Valor del TrackBar</returns>

    ”’ <remarks></remarks>

    Public ReadOnly Property Change() As Integer

        Get

            Return mChange

        End Get

    End Property

End Class

 

 

[C#]

using System;

 

/// <summary>

/// Encapsula el argumento del evento, en este caso es un entero

/// que representa al valor del TrackBar.

/// </summary>

/// <remarks>La clase hereda de EventArgs.</remarks>

class TrackBarChangeEventsArgs : EventArgs

{

    private int mChange;

 

    /// <summary>

    /// Constructor

    /// </summary>

    /// <param name=”pChange”>Valor del TrackBar.</param>

    /// <remarks></remarks>

    public TrackBarChangeEventsArgs(int pChange)

    {

        this.mChange = pChange;

    }

 

    /// <summary>

    /// Publica el valor del argumento del evento, en este caso

    /// el valor del TrackBar.

    /// </summary>

    /// <value></value>

    /// <returns>Valor del TrackBar</returns>

    /// <remarks></remarks>

    public int Change

    {

        get

        {

            return mChange;

        }

    }

}

 

Podemos ver que la clase deriva de EventArgs, tiene un constructor que recibe como parámetro el valor del TrackBar y publica al mismo mediante una propiedad Read Only.

Ahora veamos la clase encargada de publicar el evento, en el ejemplo es TrackBarAdministrador, en ella es donde se declara el Delegate de nombre TrackBarChangeEventHandler, que, como mencioné antes, recibe dos parámetros uno de tipo Object que contiene al objeto que disparó el evento y otro que deriva de EventArgs, esta ves es TrackBarChangeEventArgs.

A continuación se declara el evento OnTrackBarChangeHandler del tipo Delegate TrackBarChangeEventHandler.

La clase tiene un único método llamado ChangeTrackBar que acepta un sólo parámetro de tipo entero que es el valor del TrackBar. En este método se declara una variable llamada e del tipo de la clase TrackBarChangeEventsArgs (la que encapsula y publica el valor del TrackBar) y se le pasa el parámetro que se recibió, el entero que representa el valor del TrackBar. Ahora se dispara el evento OnTrackBarChangeHandler pasándole como parámetros el propio objeto (que es una instancia de la clase TrackBarAdministrador) y con esto queda publicado el evento.

Veamos la clase:

[VB]

Imports System

 

”’ <summary>

”’ Administra el evento de cambio de valor del TrackBar.

”’ </summary>

”’ <remarks></remarks>

Class TrackBarAdministrador

    ”’ <summary>

    ”’ Declaro un Delegate de nombre TrackBarChangeEventHandler. A

    ”’ Continuación declaro un evento del tipo del Delegate, que

    ”’ será el evento a propagar.

    ”’ </summary>

    ”’ <param name=”source”>Parámetro de entrada de tipo Object</param>

    ”’ <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    ”’ <remarks>Esta es la clase que administra el evento a producirse al

    ”’ cambiar el valor del TrackBar</remarks>

    Public Delegate Sub TrackBarChangeEventHandler(ByVal source As Object, ByVal e As TrackBarChangeEventsArgs)

    Public Event OnTrackBarChangeHandler As TrackBarChangeEventHandler

 

    ”’ <summary>

    ”’ Método que recibe el valor a propagar.

    ”’ </summary>

    ”’ <param name=”pChange”>Valor del TrackBar a propagar.</param>

    ”’ <remarks></remarks>

    Public Sub ChangeTrackBar(ByVal pChange As Integer)

        Dim e As TrackBarChangeEventsArgs = New TrackBarChangeEventsArgs(pChange)

        RaiseEvent OnTrackBarChangeHandler(Me, e)

    End Sub

End Class

[C#]

using System;

 

/// <summary>

/// Administra el evento de cambio de valor del TrackBar.

/// </summary>

/// <remarks></remarks>

class TrackBarAdministrador

{

    public event TrackBarChangeEventHandler OnTrackBarChangeHandler;

 

    /// <summary>

    /// Método que recibe el valor a propagar.

    /// </summary>

    /// <param name=”pChange”>Valor del TrackBar a propagar.</param>

    /// <remarks></remarks>

    public void ChangeTrackBar(int pChange)

    {

        TrackBarChangeEventsArgs e = new TrackBarChangeEventsArgs(pChange);

        OnTrackBarChangeHandler(this, e);

    }

 

    /// <summary>

    /// Declaro un Delegate de nombre TrackBarChangeEventHandler. A

    /// Continuación declaro un evento del tipo del Delegate, que

    /// será el evento a propagar.

    /// </summary>

    /// <param name=”source”>Parámetro de entrada de tipo Object</param>

    /// <param name=”e”>Parámetro de entrada de tipo TrackBarChangeEventsArgs</param>

    /// <remarks>Esta es la clase que administra el evento a producirse al

    /// cambiar el valor del TrackBar</remarks>

    public delegate void TrackBarChangeEventHandler(object source, TrackBarChangeEventsArgs e);

}

 

Nos queda por ver la clase engargada de notificar la ocurrencia del evento que en este caso se llama TrackBarObservador.

Si bien la clase tiene este nombre, esto no significa que estemos aplicando el patrón Observer, para quien le interese este patrón acá hay un artículo descriptivo.

Esta clase tiene un constructor que acepta como parámetro un objeto del tipo de la clase TrackBarAdministrador, lo guarda en una variable local y vincula al evento OnTrackBarChangeHandler declarado en la clase TrackBarAdministrador al método OnTrackBarChange definido más adelante en esta misma clase. Este método es donde se realizan las suscripciones de los formularios Form2 y Form3 que serán notificados del cambio en el TrackBar.

[VB]

Imports System

 

”’ <summary>

”’ Informa a los formularios sobre el evento que administra TrackBarAdministrador.

”’ </summary>

”’ <remarks></remarks>

Class TrackBarObservador

    ”’ <summary>

    ”’ Variable local del tipo de la clase que administra el evento

    ”’ a producirse al cambiar el vaor del TrackBar.