Cooperator framework

Muchas gracias por la respuesta a Daniel A. Calvin y a Eugenio
Serrano.

Me ha servido bastante para aclarar y confirmar ideas que ya venia
pensando.

Creo que un ejemplo que mas o menos refleja la utilizacion de objetos y
el enlace a datos es el que viene en la pagina:

http://www.microsoft.com/spanish/ms...ample1.asp

El codigo puede descargarse en esta direccion. La que viene en la web
es erronea.

http://asp.net/guidedtour2/Res/GeekSpeak.zip

El codigo con la creacion de la clase y sus miembros está en el
archivo Blog.cs del directorio app_code.

En este ejemplo se utiliza para el enlace de datos con el control, un
componente ObjectDataSource.

¿Es más o menos este ejemplo, lo que representa la programacion con
objetos y su acceso a datos?, con las objeciones que podrais añadir,
claro.

gracias, salu2

Va por partes

"Vyacheslav Popov" wrote:

Hola Eugenio, tengo 3 preguntas.

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

Que pasa si te aparece un nuevo campo en la tabla ? Para esos casos,
puedes
generar los procedimientos almacenados nuevamente, y tambien puedes
decirle
al generador que te genere las clases nuevamente, pero solo la parte
automatica. De esta forma no te pisa el codigo que tu ya hayas escrito en
ellas.

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

No es UML, es una aplicacion windows donde aparecen todas la entidades y
por
cada entidad (y sus propiedades) tienes distintas opciones para el
generador.

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; }
}
.
}

Una de las cosas que puedes personalizar antes de generar, es justamente
eso. Solamente tienes que seleccionar que propiedad quieres que sea
ReadOnly
y listo. El generador ya te lo genera como tu quieres. Y ademas, si hay
alguna otra opcion que tu quieres agregar y nosotros no lo hemos incluido,
puedes editar los templates, que estan escritos en C# y modificarlos para
que
le generador genere lo que tu quieras.
Y si no te gusta C#, puedes crearte tu propia plantilla en cualquier
lenguaje .Net que desees

Un abrazo,
Eugenio Serrano

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
>>
>>
>>

distintas alternativas y probando. Y no dije que LINQ tiene un ORM por
dentro, solo digo que aqui no hay magia, y en LINQ no estas trabajando sobre
la base de datos presicamente.

Novoa:
Yo de ti me mantendría alejado de todo esto. Microsoft estaba
desarrollando un "framework" de este tipo, pero lo abandonó en favor
de LINQ. Creo que fue una buena decisión.

Calvin:
El framework que mencionas es Object Space y debo darte una noticia mucho de
lo que tanto te gusta de LinQ es Object Space, esta metido dentro.

distintas alternativas y probando. Y no dije que LINQ tiene un ORM por
dentro, solo digo que aqui no hay magia, y en LINQ no estas trabajando sobre
la base de datos presicamente.

Novoa:
Yo de ti me mantendría alejado de todo esto. Microsoft estaba
desarrollando un "framework" de este tipo, pero lo abandonó en favor
de LINQ. Creo que fue una buena decisión.

Calvin:
El framework que mencionas es Object Space y debo darte una noticia mucho de
lo que tanto te gusta de LinQ es Object Space, esta metido dentro.

> distintas alternativas y probando. Y no dije que LINQ tiene un ORM por
> dentro, solo digo que aqui no hay magia, y en LINQ no estas trabajando sobre
> la base de datos presicamente.

Ahí metí la pata. Es verdad, no lo habías dicho tú. Lo dijo Daniel Calvin, pongo la cita:

>>Novoa:
>> Yo de ti me mantendría alejado de todo esto. Microsoft estaba
>> desarrollando un "framework" de este tipo, pero lo abandonó en favor
>> de LINQ. Creo que fue una buena decisión.
>Calvin:
>El framework que mencionas es Object Space y debo darte una noticia mucho de
>lo que tanto te gusta de LinQ es Object Space, esta metido dentro.

No sé mucho sobre Object Spaces, solo lo que veo a traves de estos enlaces
http://msdn.microsoft.com/library/d...spaces.asp
http://blogs.msdn.com/aconrad/archi...08679.aspx
De ahí que me quedase la duda de si LINQ se hizo con lo "aprovechable" de Object Spaces
o es otro planteamiento.

Saludos