Cooperator framework

Además que si de verdad le leyeses (omitiendo esas frases poco apropiadas)
verías que él también es una fuente de información y da alternativas.
Por ejemplo, recientemente ha indicado:

* La forma de navegar a través de los registros en un formulario
con simples consultas sql, sin traerse las claves primarias de toda la
tabla.

* También ha puesto ejemplos de reglas de negocio que se pueden plasmar
solo con sql. Para el que le interese ese método, claro.

Yo entro en este foro para aprender cosas sueltas leyendo unos cuantos
mensajes,
normalmente la información la dan los MVP pero resulta que a través de las
charlas
que rodean a este hombre aparecen cosas muy prácticas, que por supuesto me
apunto.
No me digas que por este motivo no debería andar por aquí.

Por cierto que yo suelo ver Gran Hermano y acabas de decir que es basura.
¿debo
considerarlo un insulto por tu parte? ;-D

De acuerdo, pero linda, no hay que ser tan sensible tampoco. Aquí no nos
estamos ni viendo la cara.

Hola Vyacheslav Popov:

Exacto, creo que me vas entendiendo. El generador de Cooperator, genera
Stored Procedures, Clases y Mappers para todas la entidades de tu negocio.
Pero antes de generarlas, te deja modelar tus entidades en una herramienta
donde tu puedes editar montones de cosas, como por ejemplo, que los
renglones
de tu factura se carguen por lazyload, o si tal campo de la tabla no
quieres
que aparezca como una propiedad en tu clase, o por ejemplo, una tabla
simple
se mantenga en cache, para que no se este leyendo a cada rato.

Una vez que has configurado esa herramienta, el codigo se genera y ya
tienes
tu clases listas para usarlas.

En algunos dias vamos a poner una version para que puedan bajar.

Saludos y Gracias !
Eugenio Serrano


"Vyacheslav Popov" wrote:

Mostrar la cita

Una explicación estupenda Eugenio!

Coincido contigo y quiero extender alguna cuestión mas.

Eugenio: > Con Cooperator Framework, intentamos solucionar los problemas
de
persistir
> nuestros objetos en una base de datos relacional como SQL Server y
> hacerle
> la
> vida mas fácil a quien quiera usar la programación orientada a objetos
> en
> sus
> sistemas.

Pues bien, si ya se ha entendido para usar objetos de dominio frente a
dataSet, podemos seguir.
El problema que presenta trabajar con objetos frente a dataSet es la
creación y actualización de éstos, es decir:
Para llenar un DataSet a partir de la base de datos es tan fácil como
sigue:

SqlConnection con = new SqlConnection("cadena de conexión");
SqlDataAdapter da = new SqlDataAdapter("select * from.", con);
DataSet ds = new DataSet();
da.Fill(ds);

!Y ya está! el dataSet esta lleno de datos.
Sin embargo para llenar de datos tus objetos de dominio hay que trabajar
bastante más:

Una vez obtenido el dataSet del modo anterior (por ejemplo, pero no
necesariamente), creamos objeto del dominio...
Factura miFactura = Factura();
miFactura.Fecha = (DateTime) ds.Tables["Factura"].Rows["Fecha"];
miFactura.Numero = ds.Tables["Factura"].Rows["Numero"];
..
foreach (DataRow dr in ds.Tables["Detalle"].Rows) {
Producto producto = CatalogoProductos.Buscar(dr["idProducto"]);
miFactura.AñadirLinea(producto, (int) dr["idCantidad"]);

}

Y más código por estilo para cada uno de los objetos del dominio
Luego
lo puedes factorizar, mejorar, etc... pero saldrán muchas líneas de
código
casi mecánico.

Ahora bien, lo que pretende hacer Cooperator es automatizar esta tarea de
escribir este código pesado de traducción o mapeo (esta técnica se conoce
como Mapeo Objeto-Relacional (ORM)), creando el ORM especifico o
personalizado para tus objetos del dominio de tal modo que no tendremos
que
preocuparnos por eso y simplemente hacemos lo siguiente:

Factura miFactura = FacturaMapper.GetOne(2,"0001-00003454");

Fíjate que es más claro, y a con menos código a escribir que en el primer
ejemplo con DataSet.

Luego en el mercado existen muchos ORM de código libre y comerciales que
sirven para cualquier modelo de dominio pero la sintaxis ya no es tan
clara
y personalizada sino genérico..

Saludos.

"Eugenio Serrano" escribió en
el
mensaje news:
> Hola koldo, intentare explicar un poco:
>
> Los datasets son objetos que representan Tablas, Filas, Columnas,
> Relaciones, etc.
> Los datasets sin tipo, son objetos genericos que soportan cualquier
> tipo
> de
> tablas.
> Existen tambien Dataset tipados (Typed Dataset), que es otro objecto
> que
> hereda de Dataset pero que esta personalizado para tus propias tablas.
> Por
> ejemplo, en vez usar algo asi MiDataset.Tables(0), puedes referirte a
> MiDataset.ClientesDataTable
> Bien, ahora supone que tienes que representar una Factura. En ese caso
> si
> lo
> representas con un dataset necesitas un dataset que tenga 2 tablas (que
> puede
> ser tipado o no), pero que tenga 2 tablas al menos. Una tabla donde
> guardas
> la cabecera de la factura (Fecha, TipoComprobante, NumeroComprobante,
> etc)
> y
> otra tabla donde guardas el detalle de la factura. (Los renglones que
> tiene
> tu comprobante)
>
> El problema que nosotros vemos a los datasets, es que contien cantidad
> de
> objetos que no tienen mucho que ver con la factura en si. (El dataset
> es
> un
> objeto que tiende dentro cantidad de propiedades para representan las
> tablas,
> filas, columnas, relaciones, etc)
>
> Ahora, que tal si tu tienes una objeto Factura, que solo tiene los
> datos
> de
> la factura, incluyendo una propiedad que es una coleccion donde se
> representan todos los renglones, esa clase intenta representar una
> Factura
> y
> no tablas donde guardo los datos de la factura (como sucede con los
> datasets). De esta forma podrias hacer algo asi:
>
> 'Creo un objeto del tipo factura
> Dim miFactura as Factura
>
> 'Obtengo de la base de datos, la factura.
> miFactura = FacturaMapper.GetOne(2,"0001-00003454")
>
> 'Aclaro que el objeto FacturaMapper (que ha sigo generado
> automaticamente)
> ,
> ya sabe que debe devolver un objeto del tipo Factura, y que ademas, ya
> sabe
> que para crear ese objeto debe consultar 2 tablas en la base de datos.
> (La
> cabecera y el detalle)
>
> 'Ahora puedo hacer algo asi:
> Dim PrecioRenglon as Decimal
> Dim ImporteFactura as Decimal
> PrecioRenglon = miFactura.Renglones(2).Importe
> ImporteFactura = miFactura.Total
>
> 'Si en esta ultima linea, te confundes y escribes por ejemplo Tutal, en
> vez
> de Total, tu codigo no compilará, ya que la clase es totalmente tipada.
> Esto
> quiere decir que propiedad tiene un tipo especifico. Lo mismo pasaria
> si
> hubieramos declarado ImporteFactura as String, no compila porque
> miFactura.Total es del tipo Decimal.
>
> Nosotros creemos que esta forma de representar tus entidades de negocio
> es
> mas claro que los datasets. Ademas en los datasets se crean cantidad de
> objetos en memoria que nunca usas. Y esos objetos consumen tiempo para
> crearse y espacion en la memoria.
> Con Visual Studio 2005, tienes la posiblidad de enlazar los objetos a
> los
> controles, y en nuestras pruebas, hemos conseguido llenar por ejemplo,
> un
> grid con objetos mucho mas rapido que con Datasets (Y eso tiene mucho
> sentido
> por lo que te decia al principio, los dataset te crean cantidad de
> objetitos
> dentro que consumen recursos)
>
> Hay muchisima gente que no le gusta programar asi, y la respeto. Yo he
> programado cantidad de años de esa forma, y tengo sistemas funcionando
> que
> estan programado de esa forma.
> Los que programan asi, en su cabeza siguen pensando en un modelo
> centrado
> en datos, que es totalmente valido.
> Nosotros intentamos pensar las entidades como objetos. Cuando pienso en
> una
> factura pienso en una entidad, (no en las tablas donde esta guardada)
>
> Ni un modelo es mejor que otro, son solo diferentes formas de ver las
> cosas... Cada modelo tiene venjas y desventajas.
>
> Las ventajas de trabajar con objetos, es que a nivel de codigo es todo
> mucho
> mas facil y natural, puedes solucionar problemas mas complejos de una
> forma
> mas natural y mas rapido, pero el problema que tienen es que hay una
> impedancia entre este modelo y el modelo relacional. Esto es, nuestro
> objeto
> Factura, que en memoria es UN SOLO OBJETO, en las tablas son DOS
> TABLAS.
>
> Con Cooperator Framework, intentamos solucionar los problemas de
> persistir
> nuestros objetos en una base de datos relacional como SQL Server y
> hacerle
> la
> vida mas facil a quien quiera usar la programacion orientada a objetos
> en
> sus
> sitemas.
>
> Saludos,
> Eugenio Serrano

Digo que me lo paso bomba viendo como se discuten cosas que se vienen dando
como buenas a bombo y platillo (en general, no va por Cooperator).
Quiero ver ejemplos y alternativas, y no simplemente una jerga de palabras
como RUP, Xtreme Programming, ORM... Hay tropecientos ORM en el mercado.
¿por qué tantos? ¿es que todos dan problemas? ¿y por qué Microsoft saca LINQ
en vez de su propio ORM? ¿es LINQ un ORM por dentro como apuntaba Eugenio?
¿hasta que grado? ¿que pasa si en mi departamento dedicamos dos años a desarrollar sobre
un ORM y luego la cosa no resulta? ¿me voy buscando otro curro?
y así un largo etcétera...

Yo entro en este foro para aprender cosas sueltas leyendo unos cuantos mensajes,
normalmente la información la dan los MVP pero resulta que a través de las charlas
que rodean a este hombre aparecen cosas muy prácticas, que por supuesto me apunto.
No me digas que por este motivo no debería andar por aquí.

Hola Eugenio, tengo 3 preguntas.

1. ¿Cual será la necesidad de modificar posteriormente los procedimientos
almacenados generados de forma automática?

2. ¿En que consiste el modelado de las entidades con la herramienta?
¿Diagramas de clases UML?

3. ¿Cómo se crean las clases? me explico:
Al usar cualquier ORM genérico se "exige" declarar las propiedades de la
clase en modo lectura-escritura lo que a mi, personalmente, no termina de
convencer. Por ejemplo:

public class Factura
{
.
public Factura() {...}

public int Numero
{
get { return numero; }
set { numero= value; }
}
.
}

// Preferería

public class Factura
{
.
public Factura(int numero) {...}

public int Numero
{
get { return numero; }
}
.
}

Saludos.


"Eugenio Serrano" escribió en el
mensaje news:
> Hola Vyacheslav Popov:
>
> Exacto, creo que me vas entendiendo. El generador de Cooperator, genera
> Stored Procedures, Clases y Mappers para todas la entidades de tu negocio.
> Pero antes de generarlas, te deja modelar tus entidades en una herramienta
> donde tu puedes editar montones de cosas, como por ejemplo, que los
> renglones
> de tu factura se carguen por lazyload, o si tal campo de la tabla no
> quieres
> que aparezca como una propiedad en tu clase, o por ejemplo, una tabla
> simple
> se mantenga en cache, para que no se este leyendo a cada rato.
>
> Una vez que has configurado esa herramienta, el codigo se genera y ya
> tienes
> tu clases listas para usarlas.
>
> En algunos dias vamos a poner una version para que puedan bajar.
>
> Saludos y Gracias !
> Eugenio Serrano
>
>
> "Vyacheslav Popov" wrote:
>
>> Una explicación estupenda Eugenio!
>>
>> Coincido contigo y quiero extender alguna cuestión mas.
>>
>> Eugenio: > Con Cooperator Framework, intentamos solucionar los problemas
>> de
>> persistir
>> > nuestros objetos en una base de datos relacional como SQL Server y
>> > hacerle
>> > la
>> > vida mas fácil a quien quiera usar la programación orientada a objetos
>> > en
>> > sus
>> > sistemas.
>>
>> Pues bien, si ya se ha entendido para usar objetos de dominio frente a
>> dataSet, podemos seguir.
>> El problema que presenta trabajar con objetos frente a dataSet es la
>> creación y actualización de éstos, es decir:
>> Para llenar un DataSet a partir de la base de datos es tan fácil como
>> sigue:
>>
>> SqlConnection con = new SqlConnection("cadena de conexión");
>> SqlDataAdapter da = new SqlDataAdapter("select * from.", con);
>> DataSet ds = new DataSet();
>> da.Fill(ds);
>>
>> !Y ya está! el dataSet esta lleno de datos.
>> Sin embargo para llenar de datos tus objetos de dominio hay que trabajar
>> bastante más:
>>
>> Una vez obtenido el dataSet del modo anterior (por ejemplo, pero no
>> necesariamente), creamos objeto del dominio...
>> Factura miFactura = Factura();
>> miFactura.Fecha = (DateTime) ds.Tables["Factura"].Rows["Fecha"];
>> miFactura.Numero = ds.Tables["Factura"].Rows["Numero"];
>> ..
>> foreach (DataRow dr in ds.Tables["Detalle"].Rows) {
>> Producto producto = CatalogoProductos.Buscar(dr["idProducto"]);
>> miFactura.AñadirLinea(producto, (int) dr["idCantidad"]);
>>
>> }
>>
>> Y más código por estilo para cada uno de los objetos del dominio
>> Luego
>> lo puedes factorizar, mejorar, etc... pero saldrán muchas líneas de
>> código
>> casi mecánico.
>>
>> Ahora bien, lo que pretende hacer Cooperator es automatizar esta tarea de
>> escribir este código pesado de traducción o mapeo (esta técnica se conoce
>> como Mapeo Objeto-Relacional (ORM)), creando el ORM especifico o
>> personalizado para tus objetos del dominio de tal modo que no tendremos
>> que
>> preocuparnos por eso y simplemente hacemos lo siguiente:
>>
>> Factura miFactura = FacturaMapper.GetOne(2,"0001-00003454");
>>
>> Fíjate que es más claro, y a con menos código a escribir que en el primer
>> ejemplo con DataSet.
>>
>> Luego en el mercado existen muchos ORM de código libre y comerciales que
>> sirven para cualquier modelo de dominio pero la sintaxis ya no es tan
>> clara
>> y personalizada sino genérico..
>>
>> Saludos.
>>
>> "Eugenio Serrano" escribió en
>> el
>> mensaje news:
>> > Hola koldo, intentare explicar un poco:
>> >
>> > Los datasets son objetos que representan Tablas, Filas, Columnas,
>> > Relaciones, etc.
>> > Los datasets sin tipo, son objetos genericos que soportan cualquier
>> > tipo
>> > de
>> > tablas.
>> > Existen tambien Dataset tipados (Typed Dataset), que es otro objecto
>> > que
>> > hereda de Dataset pero que esta personalizado para tus propias tablas.
>> > Por
>> > ejemplo, en vez usar algo asi MiDataset.Tables(0), puedes referirte a
>> > MiDataset.ClientesDataTable
>> > Bien, ahora supone que tienes que representar una Factura. En ese caso
>> > si
>> > lo
>> > representas con un dataset necesitas un dataset que tenga 2 tablas (que
>> > puede
>> > ser tipado o no), pero que tenga 2 tablas al menos. Una tabla donde
>> > guardas
>> > la cabecera de la factura (Fecha, TipoComprobante, NumeroComprobante,
>> > etc)
>> > y
>> > otra tabla donde guardas el detalle de la factura. (Los renglones que
>> > tiene
>> > tu comprobante)
>> >
>> > El problema que nosotros vemos a los datasets, es que contien cantidad
>> > de
>> > objetos que no tienen mucho que ver con la factura en si. (El dataset
>> > es
>> > un
>> > objeto que tiende dentro cantidad de propiedades para representan las
>> > tablas,
>> > filas, columnas, relaciones, etc)
>> >
>> > Ahora, que tal si tu tienes una objeto Factura, que solo tiene los
>> > datos
>> > de
>> > la factura, incluyendo una propiedad que es una coleccion donde se
>> > representan todos los renglones, esa clase intenta representar una
>> > Factura
>> > y
>> > no tablas donde guardo los datos de la factura (como sucede con los
>> > datasets). De esta forma podrias hacer algo asi:
>> >
>> > 'Creo un objeto del tipo factura
>> > Dim miFactura as Factura
>> >
>> > 'Obtengo de la base de datos, la factura.
>> > miFactura = FacturaMapper.GetOne(2,"0001-00003454")
>> >
>> > 'Aclaro que el objeto FacturaMapper (que ha sigo generado
>> > automaticamente)
>> > ,
>> > ya sabe que debe devolver un objeto del tipo Factura, y que ademas, ya
>> > sabe
>> > que para crear ese objeto debe consultar 2 tablas en la base de datos.
>> > (La
>> > cabecera y el detalle)
>> >
>> > 'Ahora puedo hacer algo asi:
>> > Dim PrecioRenglon as Decimal
>> > Dim ImporteFactura as Decimal
>> > PrecioRenglon = miFactura.Renglones(2).Importe
>> > ImporteFactura = miFactura.Total
>> >
>> > 'Si en esta ultima linea, te confundes y escribes por ejemplo Tutal, en
>> > vez
>> > de Total, tu codigo no compilará, ya que la clase es totalmente tipada.
>> > Esto
>> > quiere decir que propiedad tiene un tipo especifico. Lo mismo pasaria
>> > si
>> > hubieramos declarado ImporteFactura as String, no compila porque
>> > miFactura.Total es del tipo Decimal.
>> >
>> > Nosotros creemos que esta forma de representar tus entidades de negocio
>> > es
>> > mas claro que los datasets. Ademas en los datasets se crean cantidad de
>> > objetos en memoria que nunca usas. Y esos objetos consumen tiempo para
>> > crearse y espacion en la memoria.
>> > Con Visual Studio 2005, tienes la posiblidad de enlazar los objetos a
>> > los
>> > controles, y en nuestras pruebas, hemos conseguido llenar por ejemplo,
>> > un
>> > grid con objetos mucho mas rapido que con Datasets (Y eso tiene mucho
>> > sentido
>> > por lo que te decia al principio, los dataset te crean cantidad de
>> > objetitos
>> > dentro que consumen recursos)
>> >
>> > Hay muchisima gente que no le gusta programar asi, y la respeto. Yo he
>> > programado cantidad de años de esa forma, y tengo sistemas funcionando
>> > que
>> > estan programado de esa forma.
>> > Los que programan asi, en su cabeza siguen pensando en un modelo
>> > centrado
>> > en datos, que es totalmente valido.
>> > Nosotros intentamos pensar las entidades como objetos. Cuando pienso en
>> > una
>> > factura pienso en una entidad, (no en las tablas donde esta guardada)
>> >
>> > Ni un modelo es mejor que otro, son solo diferentes formas de ver las
>> > cosas... Cada modelo tiene venjas y desventajas.
>> >
>> > Las ventajas de trabajar con objetos, es que a nivel de codigo es todo
>> > mucho
>> > mas facil y natural, puedes solucionar problemas mas complejos de una
>> > forma
>> > mas natural y mas rapido, pero el problema que tienen es que hay una
>> > impedancia entre este modelo y el modelo relacional. Esto es, nuestro
>> > objeto
>> > Factura, que en memoria es UN SOLO OBJETO, en las tablas son DOS
>> > TABLAS.
>> >
>> > Con Cooperator Framework, intentamos solucionar los problemas de
>> > persistir
>> > nuestros objetos en una base de datos relacional como SQL Server y
>> > hacerle
>> > la
>> > vida mas facil a quien quiera usar la programacion orientada a objetos
>> > en
>> > sus
>> > sitemas.
>> >
>> > Saludos,
>> > Eugenio Serrano
>>
>>
>>