Tipos Genericos

[doctorhd]

Las clases que expongo son parte de la capa de datos de una aplicación, mas específicamente TField almacena la definición de un campo de la base de datos, junto con TDomain que almacena las características del dominio al que pertenece dicho campo, ya explicado lo anterior, lo que quería lograr era asignar a Tfield que representa al campo, el tipo de dominio que este posee, el cual puede ser de distinto tipo (string, integer, etc), debido a esto pensé que usar tipos genéricos era buena idea para almacenar el tipo de dominio especifico de cada campo. Se que se puede usar herencia de la clase base TDomian para conseguir el mismo efecto, pero haciendo esto necesariamente hay que hacer cast para acceder a la clase descendiente, cuestión que quería evitar para hacer transparente el acceso a los datos a los clientes de dichas clases. La aplicación cliente no tiene porque saber que tipo de Dominio tiene un campo, si las restricciones de ingreso de dicho campo, las cuales son accesibles desde las clases descendientes...
Espero haberme hecho entender..

Saludos.

[[AgustinOrtu]]

La clase TField ya existe en Delphi. De todos modos, segundo a mamcx y creo que no esta bien diseñado

[ecfisa]

Hola doctorhd.

Opino igual que AgustinOrtu. De la clase TField podes obtener los datos de las columnas relativas a la tabla asociada a un TDataSet.

(O he perdido el rumbo y no estoy entendiendo lo que intentas hacer...)


Saludos

[mamcx]

Empezado por doctorhd

Las clases que expongo son parte de la capa de datos de una aplicación

Ok, estas haciendo un ORM . Hacer un ORM es de lo primero que hago cuando aprendo un nuevo lenguaje (y he hecho, con re-escrituras, un monton!) y justo ahora estoy diseñando un lenguaje relacional... y si vieras lo particularmente complejo que puede volverse el asunto.

El punto es que las BD y la OO no se llevan bien (tienen un "impedance mismatch"):

http://clubdelphi.com/foros/showpost...76&postcount=2

----

La parte mas importante del modelo relacional, es entender que una tabla es un valor, no un objeto!. Un valor como "1", "true", "hello world", Array(1, 2, 3), o sea como si en cada "momento" es un pantallazo estatico de la informacion, como una constante. Por lo tanto, una tabla es como un array, solo con multiples columnas.

----

Te voy a ahorrar un monton de tiempo y muchas vueltas de cabeza y te digo que:

1- Usa un ORM que ya este hecho. No creo que ninguno realmente sea bueno, pero sera mucho mejor que hacerlo. Te lo digo despues de intentar varios ORM en Delphi

2- El modelo que tiene sentido y exito en la OO es hacer como este proyecto:

https://github.com/StackExchange/dapper-dot-net

Código PHP:

public class Dog
{
    public int? Age { get; set; }
    public Guid Id { get; set; }
    public string Name { get; set; }
    public float? Weight { get; set; }

    public int IgnoredProperty { get { return 1; } }
}            

var guid = Guid.NewGuid();
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

dog.Count()
    .IsEqualTo(1);

dog.First().Age
    .IsNull();

dog.First().Id
    .IsEqualTo(guid);

// NOTA EN ESPECIAL ESTO
var rows = connection.Query("select 1 A, 2 B union all select 3, 4");

((int)rows[0].A)
   .IsEqualTo(1); 


Este tipo de proyectos se llaman "micro-ORM". Lo *importante* es que no peleean en contra de la BD. No intentan replicar (pobremente, debido a ser lenguajes OO) lo que la BD ya tiene/sabe. La BD es mejor haciendo consultas, ordenando, filtrando, uniendo y haciendo introspeccion de si misma que cualquier ORM.


Nota como la interface de Dapper no le huye al SQL. Ademas, es mas rapido que los ORM tradicionales de .NET (obvio: No esta re-implementando gran cosa).

La unica cosa sofisticada es que puede usarse el LINQ, que es algo facil en .NET. No se que tanto se pueda con Delphi hacer eso, pero creo que una version moderna de Delphi es muy viable.

Estudia dapper y lee sobre los micro-ORM que te abriran la mente y simplificaran mucho la vida.

P.D: Delphi basicamente permite hacer algo muy simple: Usa TClientDataset para obtener resultados, y una clase plana para ejecutar SQL. Un micro-ORM asi se puede resolver con unos, digamos, 7-8 funciones y eso es todo.

Lo que hace un micro-ORM es solo mapear una tabla a una clase, y ojala una clase "plana": Osea= Sin metodos, funciones ni propiedades complejas. Quizas de extra, hacer un ayudador para hacer query o para generar SQL.

Ya que como te explique, una tabla es un valor, esto es lo que realmente tiene sentido:

Código PHP:

OO.Cliente.Nombre = DB.Cliente.Nombre 


Sin NADA MAS. Nota como la clase "Dog" es identica a un tipo "Record" de pascal.

Esto significa que si tienes una vista o un SQL que retorna campos que no son identicos a las clases que ya tienes... no haces herencia (bueno digamos que no herencias profundas, y a lo sumo, solo heredas propiedades y YA), no haces arboles complejos de objetos, nada. Crea una clase tipo "record" adicional y ya.

Maso asi:

Código Delphi [-]

TValor = class
  property Campo1:Int
  property Campo2:Int
end

List< TValor > = getData("SELECT 1 AS Campo1, 2 AS Campo2")

Nota que (aparte de usar un TClientDataset, que sigue siendo demasiado pero ya esta inventado) este es la UNICA forma que *realmente* tiene sentido y *verdaderamente* refleja lo que es la BD. Una tabla no tiene herencia, no hay funciones, etc. Campo1:Tipo es Campo1:Tipo eso es todo.

Esto te ahorra mucho tiempo, hace el codigo mas simple, claro y veloz.

Igual, si quieres hacer clases que encapsulen estas otras ya es otro tema.

[[AgustinOrtu]]

Lo que explico Mario (si se me permite llamarte por tu nombre ) es basicamente lo que hago (intento) desde casi que inicio en el mundo del OO + Relacional

En las versiones mas modernas de Delphi es mas sencillo todavia, ya que podes crearte la clase que el te dijo, un TObjectList<TTuClase> y enlazarla por LiveBindings. En un plumazo tenes separada la logica de tu aplicacion, del acceso a los datos, de la presentacion visual

Yo creo lo mejor es dar un pequeño paso mas, y pedirle a una clase que te retorne la instancia en cuestion de la forma que el lo propone. Es decir, tus clases de negocio en un principio no tienen porque saber que van a ser guardadas en una BD

Si sigo con el ejemplo del Dog

Código Delphi [-]
TDog = class
public
  property Name: string read FName write SetAge;
  property Age: Integer read FAge write SetAge;
  procedure Run;
end;

Esa clase no sabe nada de que se la va a guadar en una BD para que sea persistente. Eso quiere decir que tu clase es testeable sin depender de ninguna BD. Podes probar que tanto las propiedades Name, como Age, como el metodo Run funcionan bien usando Unit Testing.

Luego, para levantarlo de una BD, harias algo como esto

Código Delphi [-]
function GetDog(const DogId: Integer): TDog;
begin
  Result := TDog.Create;
  OpenQuery('SELECT [Campos] from Dogs');
  Result.Name := Query.FieldByName('Name');
  Result.Age := Query.FieldByName('Age');
end;

Tambien es posible que crees otra clase, como comenta Mario, que no tenga ningun metodo, simplemente los campos que mapea de la BD. Entonces, para crear un Dog, podrias tener un constructor que recibe como parametro una instancia del TDatabaseDog de donde tomar el Name y el Age

El tema es bastante complejo pero siempre me gusta este tipo de debates

[doctorhd]

Gracias a todos por sus consejos y comentarios, la verdad no he investigado profundamente el tema de ORM y he ido construyendo el modelo que tengo en la medida que la necesidad a ido surgiendo, actualmente tengo un modelo de varias capas, una capa de negocios que se encarga de las validaciones y restricciones propias del negocio para con los datos, mas abajo una capa pivot que se encarga de direccionar los datos a la capa que interactua con la BD. Esta capa pivot la construí con el objetivo de permitir cambiar de proveedor de datos si así fuera necesario, por ahora trabajo con Firefird, pero la idea es extenderlo a SqlServer y Postgress. La capa que interactua con la BD recibe de la capa pivot los datos y los envía a BD, principalmente a través de procedimientos almacenados. Todo el manejo de inserciones, eliminación, update, select y demás se lo dejo a la BD (como dijo Mamcx para algo existe SQL). Solo llamo los store procedure que se encargan de realizar las tareas. Todo esto del lado del servidor y montado sobre datasnap. Por el lado del cliente la visualización de los datos a través de ClientDataSet y TDSProviderConexion.

Lo que hace un micro-ORM es solo mapear una tabla a una clase, y ojala una clase "plana": Osea= Sin métodos, funciones ni propiedades complejas.

Efectivamente así lo realizo una clase plana que se envía del cliente al servidor, inicialmente lo contrui con record por su simpleza, pero tuve que cambiar a una clase porque datasnap no soporta el tipo record como intercambio de datos entre servidor y cliente.

Las clases Tfield y TDomain, me sirven de apoyo para configurar tanto del lado del cliente como del servidor las especificaciones de cada campo, como su longitud, tipo, valores permitidos, etc. Esto me es muy útil para el ingreso y validación de los datos que suministra el usuario.

Hasta ahora mi modelo a funcionado, no digo que sea perfecto y obviamente se puede mejorar, mas aun con la experiencia de otros que ya han construido modelos con el mismo objetivo. Y como alguien dijo por ahí, para que inventar la rueda de
nuevo.

mancx, voy a revisar los enlaces y temas que me has propuesto, para expandir mis conocimientos.

Gracias a todos, un saludo...

[[AgustinOrtu]]

No "ensucies" tus clases con ese tipo de validaciones estilo "Length > 30, error, el maximo es 30". Tus clases solamente hacen su trabajo, el cual es hacer negocios.

Es muy molesto tener que, en cada setter acordarse de poner el "aqui solamente aceptamos numeros enteros!". Y de pronto como decis, no es un modelo muy flexible para andar cambiando. Incluso si queres desactivarlo seria terminar comentando medio codigo fuente. No es la tecnica mas efectiva. Y eso es, porque como se comenta en el otro hilo que hablamos este tema, OO no es la solucion a todo. Simplemente hay cosas que se resuelven mejor usando otro paradigma.

De la misma manera que cuando empiezas a ver las estructuras de datos en los primeros años que estudias programacion, te enseñan primero los simples loops iterativos, luego te dan recursion, y te das cuenta de que algunos problemas son triviales de resolver usando una u otra tecnica (ejemplo clasico de los arboles, a quien se le ocurriria usar un for para recorrer un arbol binario??).

Aca hay un ejemplo de como hacerlo usando atributos: Using attributes in Delphi

Tambien hay otra forma que es muy interesante y por lejos la mas flexible de todas, es utilizando Aspect Oriented Programming (AOP). En este video se explica como hacerlo en Delphi. AOP te permitiria, en una unit separada tener toda tu logica de validacion de datos. Solamente tocando aca, tuneas todas las validaciones que se te antojen. Esto quiere decir que tu sistema en general "no se va a dar cuenta nunca" de que alguien esta monitoreando los valores permitidos y los que no. Esto es bueno porque simplemente sacas la unit, recompilas y tadá! Ahora los nombres pueden tener todos los caracteres que de la gana.

Tambien quiere decir que seria trivial serializar los parametros de configuracion de las validaciones hasta en un tonto fichero ini y con solo unos toques ahi ya podrias por ejemplo permitir, ahora 31 caracteres en el nombre de los clientes porque al jefe de turno le parece lo mas adecuado

AOP es una tecnica sumamente poderosa, y como se explica en el video, es muy bueno para implemtentar este tipo de cosas de forma horizontal en todo el sistema, pero a la vez "transparentemente"; notar tambien los otros casos que menciona que son buenos para atacar con AOP: el Loggin. Si uno quiere andar guardando registro de todo lo que pasa, es muy molesto el tener que andar acordandose de hacerlo en cada metodo. Ademas de que molesta, porque uno cuando esta programando cierto metodo quiere concentrarse solo en lo que hace el metodo, no de avisarle a la clase logger "hey mira, entre al metodo IncrementarExistenciaProudcto, son las 3 AM del dia Martes xx/xx/xxxx, el usuario que disparo la accion se llama juan, tiene nivel de acceso modo-dios, los parametros son: [...]"

[ecfisa]

Ahora entiendo por donde van los tiros...

Como lo menciona mamcx, existe casi un punto de inflexión entre la OPP y las tecnologías de bases de datos relacionales. Son paradigmas diferentes y las soluciones que tratan de conciliarlas son pobres e ineficientes. (Object Relational Impedance Mismatch)

No es que no se pueda poner un clavo con una pinza... Es sólo que para eso, es mejor el martillo.

Saludos

[elrayo76]

Este tema me intereso mucho, ya que intento hacer algo similar y no se por donde comenzar.

Lo que en mi caso pretendo es hacer un especie de framework para la conexión con la base de datos para luego poder cambiarlo si es que cambia el motor de base de datos. Luego tendría como dijeron las clases con las propiedades que serían cada uno de los campos de la base.

Las distintas clases las usaría no solo para acualizaciónde datos, sino para consulta de los datos de las tablas, etc.

Para los tipos, tamaño etc de los campos de la base yo implementaria un diccionario de datos donde guardar esta información, así sería configurable por cada pantalla, ya que un mismo dato puede que en alguna pantalla necesite mostrarlo con un tamaño y en otra con otro (digo por no entrar en esa pantalla).

Lo que quisiera es que me orienten en como armar ese mini framework que quiero. También si saben de donde se puede sacar algún códio fuene de un mini-ORM para estudiarlo se los agradecería.

Saludos,
El Rayo