Cooperator framework

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

Mostrar la cita

Concido contigo, sin el tipo de interlocutor que representa Alfredo este
grupo sería un poco monótono.

Entonces podría ser que muchos se han equivocado de foro. Para mi un grupo
es una fuente de información y conocimiento, un sitio donde se pueda
debatir las ideas. Un sitio donde uno se limita a insultar y echar tierra
sobre el trabajo de otros solo porque no coincide con su punto de vista y
lo que es peor, no tiene los conocimientos suficientes como para demostrar
lo que dice, para mi no es entretenido, sino es una pérdida de tiempo.
Para esa clase de cosas hay programas en la televisión como Gran Hermano,
Aquí hay Tomate y toda la basura que echan en Tele 5 y Antenna 3.

> Concido contigo, sin el tipo de interlocutor que representa Alfredo este
> grupo sería un poco monótono.
>

Entonces podría ser que muchos se han equivocado de foro. Para mi un grupo
es una fuente de información y conocimiento, un sitio donde se pueda debatir
las ideas. Un sitio donde uno se limita a insultar y echar tierra sobre el
trabajo de otros solo porque no coincide con su punto de vista y lo que es
peor, no tiene los conocimientos suficientes como para demostrar lo que
dice, para mi no es entretenido, sino es una pérdida de tiempo. Para esa
clase de cosas hay programas en la televisión como Gran Hermano, Aquí hay
Tomate y toda la basura que echan en Tele 5 y Antenna 3.

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

Alfredo, hombre, habia jurado no contestarte mas, pero no he podido
contenerme.

Despues de terrible lio que has armado en este post, terminas
desdiciendote,
asegurando que jamas usarias LINQ en un sistema profesional ??
Y donde lo usarias ? Para jugar en tu casa ?

Creo que simplemente haces aguas por todos lados y no haces mas que
confundir a la gente

Si quieres que discutamos con respeto, sin insultar (diciendo por ejemplo,
que lo nuestro es basura), con gusto abrimos otro thread donde expongamos
las
ventajas y desventajas de los 2 modelos. Creo que puede ser provechoso
para
todos. Pero participare solo si no nos faltas el respeto.

Saludos,
Eugenio Serrano





"Alfredo Novoa" wrote:

Mostrar la cita

On Wed, 21 Jun 2006 20:53:43 -0300, "Daniel A. Calvin"
wrote:

>string[] cities = { "London", "Amsterdam", "San Francisco","Las Vegas",
>"Boston", "Raleigh", "Chicago", "Charlestown", "Helsinki", "Nice",
>"Dublin" };
>
> GridView1.DataSource = from city in cities
> where city.Length > 4
> orderby city
> select city.ToUpper();
> GridView1.DataBind();
>
>
>Ohhhhh, el datasource es un array de strings...
>Alfredo LinQ hace lo que vos odias con tanto fervor.

No hay nada de malo en que pueda hacer esto sino todo lo contrario,
pero esto no cambia nada las cosas. En un Sistema de Información las
reglas de negocio deben de ser aseguradas por el DBMS de todas formas.

Esto es un pequeño ejemplo de las capacidades de LINQ, pero está
clarísimo que este tipo de código nunca debería de existir en un
Sistema de Información profesional.

Por ejemplo esta capacidad se podría aprovechar en aplicaciones que no
son de bases de datos.


Saludos