Cooperator framework

19/06/2006 - 18:25 por Daniel A. Calvin | Informe spam
Amigos, les cuento que hace unos meses empezamos a trabajar con un grupo de
amigos en un proyecto para crear un framework que saque provecho de las
ventajas de .Net 2.0
La idea original fue de Eugenio Serrano y me invito a trabajar junto a el y
otros amigos.
El proyecto es un framewok de desarrollo, seguramente estarán pensando: otro
más :-)
Nos decidimos a hacer este nuevo con la idea principal de que sea bien facil
de usar y de acercar los objetos a mas gente de una forma facil.

Hemos trabajado con mucha energía estos últimos meses y hemos logrado armar
algo muy interesante según nuestra opinion.

Los objetivos que nos planteamos fueron:

- 100% Orientado a objetos
- Aplanar la curva de aprendizaje y facilitar el camino de quienes aún están
condicionados por el modelo relacional.
- No usar datasets
- No usamos reflection.
- Modelo totalmente tipado, esto significa que las clases de persistencia y
recuperacion de objetos devuelven un tipo especifico y no un tipo object.
- Debido a la potencia de VS2005 se pueden bindear estos objetos a los
controles sin escribir una linea de codigo, y aporvechar las venjas de
edicion de VS2005
- No depende de la estructura relacional, soporta cualquier tipo de
estructura de base de datos.
- No hay que modificar la Primary Key o crear un campo unique en las tablas.
- Usa stored procedures.
- Soporta concurrencia
- Las condiciones de busqueda se expresan mediante objetos específicos
tipados y extendibles por el programador que terminan ejecutando un Stored
Procedure en forma transparente.
- En la capa de negocio todo se expresa en términos del dominio, incluido
los filtros y busquedas.
- Genera código en base a scripts escritos en el lenguaje que prefiera el
programador. Por defecto estan en c#, pero puedo escribir un script en c#,
para generar código SQL, o puedo escribir un script en vb.net para generar
código c#.
- Hay un modelo propuesto de las clases que se generaran que se basa en el
modelo de datos, pero el programador, antes de generar las clases edita
dicho modelo en una herramienta muy facil de usar y define como sera el
modelo que desea crear.
- Si las opciones de modelado que provee la herramienta no alcanzan, el
programador puede editar los templates y generar su propio modelo.
- La herramienta de generacion, genera 2 archivos por cada clase usando
clases parciales pensado para que el programador solo modifique una de las
2.
Si mas tarde se agrega un nuevo campo a una tabla, se puede volver a generar
el otro archivo de manera de no "pisar" cualquier codigo que el programador
ya haya escrito en esa clase.
- Soporta transacciones desconectadas.
- Licencia tipo open source, aún no hemos optado por cual, pero será de
código abierto.

Todo esto lo logramos de forma poco invasiva, implementando interfaces y
valiendonos de las nuevas características del net framework 2.0, sobre todo
Generics y clases parciales.

El framework será publicado en un término no mayor a 60 días.

Nos gustaría mucho contar con algún retorno por parte de la comunidad,
principalmente que cosas les molesta de otras herraminetas de este tipo,
incluso que les gustaría tener y aún no han encontrado en otros frameworks.

Desde ya muchas gracias

Daniel Calvin

Preguntas similare

Leer las respuestas

#91 koldo
22/06/2006 - 13:13 | Informe spam
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
#92 Eugenio Serrano
22/06/2006 - 13:19 | Informe spam
Amigo, cuando tienes aplicaciones pequeñas, que no necesitan manejar
transacciones distribuidas, entre distintas fuentes de datos que pueden no
ser base de datos como un web service, etc, y ademas tus bases de datos son
pequeñas FoxPro funciona bien, yo lo he usado.

Entiendo que por ahi la cosa se complica un poco cuando vienes de FoxPro y
entras al mundo .Net. La verdad que con este framework (como todos los
frameworks que existen) ayudan un poco a hacer las cosas mas faciles.



"Raul" wrote:

Mostrar la cita
#93 sharpman
22/06/2006 - 13:23 | Informe spam
Y dale con lo de los insultos. Que a mí no me entretiene ver como la gente se
ofende mutuamente, lee mi otro mensaje donde yo mismo sugiero utilizar un
lenguaje más formal.

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

Si no te has enterado lo repito, pienso lo mismo que tú, que hay maneras más
amables de contestar, pero ese punto de vista tan crítico que pone Alfredo
pocos más lo dan.

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.

Además no tiene una actitud anticonocimiento como dices. En este foro de
Microsoft ha puesto ejemplos usando tecnologías de microsoft como los
TableAdapter, entre otras cosas que reconoce que es lo mejor que tenemos
a día de hoy, desde un punto de vista práctico.

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
#94 Vyacheslav Popov
22/06/2006 - 13:26 | Informe spam
Una explicación estupenda Eugenio!

Coincido contigo y quiero extender alguna cuestión mas.

Eugenio: > Con Cooperator Framework, intentamos solucionar los problemas de
persistir
Mostrar la cita
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:
Mostrar la cita
#95 Eugenio Serrano
22/06/2006 - 13:51 | Informe spam
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
Ads by Google
Search Busqueda sugerida