public abstract class DataAccess

Los Genercis son una funcionalidad nueva de .NET 2005 y por ahí trae algo similar Java en su nueva versión (no sé si ya lo hayan liberado).

Para los que han programado en C++ es algo similar a las clases parametrizadas o las TemplateCollections, no recuerdo bien como llamaban, pero seguramente recuerdan algo como:

List<Albums> list = new List<Albums>(); // Tipico de ejemplos en C++

Bueno en C# es muy similar la sintaxis y ahora estamos explotando mucho eso.

Cuando alguien piensa en generics, se le viene a la mente Collecciones.

Antes haríamos algo como:

AlbumCollection : ICollection

{

// Aquí teníamos un montón de métodos para implementar ICollection (bueno no son tantos), pero era puro código repetitivo.

}

Lo enfadoso de esto es que seguramente íbamos a necesitar más de una colección con tipo, probablemente más de 10 o 30 y no sólo para nuestros BusinessEntities. Este tipo de colecciones aún se usan y pueden verlo cuando escriban datagrid1.Rows. Ahora podríamos simplemente decir.

List<Album> list = new List<Album>();

Mmm se parece a C++?

Ok, ok, las colecciones son la parte sencilla seguramente quieren ver algo más interesante. Bueno el nuevo generis EventHandler es un buen ejemplo. Para los que han tenido que crear eventos específicos y para poder cumplir con los guidelines de Microsoft, necesitamos algo como:

public class prueba

{

Prueba()

{

// Do something cool

}

public event DelegadoEspecifico evento;

}

Por lo que necesitaban crear un delegado específico:

public delegate void DelegadoEspecifico(object o, AlgoHeredandoDeEventArgs e);

Y necesitaban tener su clase AlgoHeredandoDeEventArgs

public class AlgoHeredandoDeEventArgs : EventArgs

{

AlgoHeredandoDeEventArgs(string x, string y)

{

// Do something cooler

}

// Write some useful properties here.

}

Ok, ok, es algo sencillo, pero se puede hacer más simple sin la necesidad de tener un montón de delegados.

Digamos que necesitas otro evento, pero que ahora reciba otros EventArgs distintos, porque, porque es lo único que cambia, así que ahora es:

public event DelegadoEspecifico2 evento;

y crear otra clase public class AlgoHeredandoDeEventArgs : EventArgs {}

Bueno luego usarla: public event DelegadoEspecifico2 evento2;

Bueno los genéricos nos permiten crear delegados específicos:

public event EventHandler<AlgoHeredandoDeEventArgs> evento;

public event EventHandler<AlgoHeredandoDeEventArgs2> evento;

Realmente lo único que nos ahorramos es la declaración de los delegados, pero ya es algo.

No es el único uso. Object Builder utiliza una de las formas más interesantes de aplicar Generics. Es muy complejo para describirlo aquí, pero la parte simple la pueden ver en Enterprise Library and Object Builder.

Recientemente hemos trabajando en un DataAccessLayer/DataMappingLayer (ver Table Data GateWay y Fowler’s EAA patterns) para Windows Mobile 5.0 y el uso de generics combinado con la herencia y polimorfismo fácilitaron enormemente las cosas. De manera resumida está es la arquitectura:

(Ver diagrama).

Tenemos nuestra clase base (abstracta) DataAccess, que implemente la interfaz principal IDataAccess (en caso de que necesitemos cambiar la implementación, por ejemplo para usar otra base de datos)

Todo se vuelve bastante sencillo con Generics. Usando template methods podemos ir encapsulando la funcionalidad genérica en las tablas de más arriba en la cadena de herencia, por ejemplo DataAccess es el único lugar donde se construyen los querys para la base de datos y se ejecutan los Comandos, etc. Aparte como lo tenemos todo bien encapsulado podemos destinar más tiempo a optimizar esa parte y hacerlo muy bien una sola vez. Realmente nadie quiere escribir el mismo código muchas veces (Abrir conección, execute reader, etc). Como en este caso muchas de las tablas usan Clave y descripción del mismo tipo, tenemos una segunda Clase Abstracta que se encarga de establer dichos valores y delegar el trabajo a un nuevo Template Method (el Donet en las clases concretas). De está forma cada DataAccess como VendedoresDataAccess y Lineas DataAccess son las únicas que conocen el nombre u orden de las columnas en la base de datos y saben como establecer las propiedades al Business Entitie que queremos crear.

Claro, está sólo una forma muy simple de hacer el Mapeo de Relacional a Objetos. Es algo similar a como lo explica Martin Fowler en su libro Patterns of Enterprise Applications Architecture la diferencia es que en la implementación de Fowler los metodos regresaban clases Padres, por ejemplo una clase del tipo DomainObject en lugar de una clase del tipo Persona.

Este es el código de Fowler (Java):

Class AbstractMapper{

Protected DomainObject GetDomainObject(ResultSet rs, long id){

// Do common stuff

DomainObject result = doLoad(id,rs);

// Do some other common stuff

return result;

}

}

abstract protected DomainObject doLoad(Long id, ResultSet rs);

class PersonMapper:AbstractMapper

{

protected DomainObject doLoad(Long id, ResultSet rs){

String lastNameArg = rs.getString(2);

// get other properties

return new Person(id,lastNameArg,etc);

}

}

Los usuarios de esas clases tendrán que hacer algo como:

Person p = (Person)personMapper.GetDomainObject(1);

Los dos graves problemas son:

1. Corremos el riesgo de equivocarnos de tipo de objeto y detectarlo hasta el tiempo de ejecución en lugar de en tiempo de compilación.
2. Es ineficiente estar haciendo tanto boxing (cuando regreso el objeto person como DomainObject) y unboxing (cuando hacemos el cast de DomainObject a Person).

Aparte algún error en el tipo de datos podría venir desde PersonMapper no sólo por el cliente.

En código (C#) y usando generics se puede hacer algo como lo siguiente:

Class AbstractMapper<TBO>

where TBO: DomainObject,new()

{

Protected TBO GetDomainObject(ResultSet rs, long id){

// Do common stuff

TBO result = doLoad(id,rs);

// Do some other common stuff

return result;

}

abstract protected TBO doLoad(Long id, ResultSet rs);

}

class PersonMapper: AbstractMapper<Person>

protected Person doLoad(Long id, ResultSet rs){

String lastNameArg = rs.getString(2);

// get other properties

return new Person(id,lastNameArg,etc);

}

Y ahora los clientes pueden usarlo de la siguiente forma:

Person p = personMapper.GetDomainObject(1);

No es necesario el cast ni el boxing, ya que siempre la clase AbstracMapper estará trabajando con el tipo de Objecto concreto en lugar de con DomainObject. Por otro lado el template method de PersonMapper (doLoad) para implementar la clase abstracta necesita forzosamente regresar un objeto del tipo Person.

Algo similar aplica también con Interfaces e inclusive es mucho muy útil ya que podemos tener ciertas Interfaces Genéricas y después implementarlas desde Interfaces específicas y obligar a las clases que deseen implementar a estás últimas a que cumplan con todos los metodos.

interface IGenericMapper<TBO>{

TBO Get();

}

interface IPersonMapper:IGenericMapper<Person>{}

public class PersonMapper:IPersonMapper{

// Must implement:

Person Get(){

// Do something

}

}

Claro que ahora como parte del framework que tenemos, ya está funcionalidad quedará en el DataAccessGenérico y será suficiente con que PersonMapper tenga lo siguiente:

public class PersonMapper:DataAcccess<Person>,IPersonMapper{

// Person Get() //Ya está implementada para la clase abstracta DataAccess.

// Ahora solo debemos implementer el metodo abstracto

protected Person DoFill(Person p, reader r)

{

p.Name = r[“Name”].ToString();

return p;

}

}

Pudiera parecer medio inutil el tener la interfaz IPersonMapper, pero es que en está queremos ahora dar de alta ciertos métodos específicos como GetByName, GetByLastName(string lastName), etc.