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

#16 Alfredo Novoa
20/06/2006 - 13:13 | Informe spam
On Tue, 20 Jun 2006 06:18:49 -0400, "Carolina Alvarez"
wrote:


Modelo totalmente tipado, esto significa que las clases de persistencia y
recuperacion de objetos devuelven un tipo especifico y no un tipo object




Tiene ventajas reales ese esquema ?



Claro que no, es otra vez la rueda cuadrada.
Respuesta Responder a este mensaje
#17 Alfredo Novoa
20/06/2006 - 13:27 | Informe spam
On Mon, 19 Jun 2006 21:40:59 -0300, "Daniel A. Calvin"
wrote:

¿Que ventajas tendrá frente al proyecto LINQ?


Ninguna ventaja, simplemente podras aplicar LinQ sobre las colecciones y
entidades de Cooperator



¿Y puedes aplicar juntas, uniones, diferencias, agregaciones (group
by), etc sobre esas colecciones?

¿Que ventaja tiene con respecto a aplicar estas operaciones
algebraicas directamente sobre el SGBD?
Respuesta Responder a este mensaje
#18 Vyacheslav Popov
20/06/2006 - 13:59 | Informe spam
¿Cuales son las nuevas características frente a ORM existentes, tales
como, NHibirnate, ObjectMapper.Net, etc..?



Cooperator no es un ORM, va a ir un paso mas alla, vas a poder integrar
facilmente WWF y WCF.
En la segunda versión que publiquemos, tal vez, solo tal vez, incluira
algo para implementar aplicaciones distribuidas en forma transparente.

Algo asi como un WCF del sub-desarrollo.. ;-)



WCF esta orientado a programación basada en atributos. La programación
basada en atributos se consigue gracias a reflection. Luego, la declaración
" - No usamos reflection" es falsa!
Respuesta Responder a este mensaje
#19 Alfredo Novoa
20/06/2006 - 14:14 | Informe spam
On Tue, 20 Jun 2006 13:59:41 +0200, "Vyacheslav Popov"
wrote:

¿Cuales son las nuevas características frente a ORM existentes, tales
como, NHibirnate, ObjectMapper.Net, etc..?



Cooperator no es un ORM, va a ir un paso mas alla, vas a poder integrar
facilmente WWF y WCF.
En la segunda versión que publiquemos, tal vez, solo tal vez, incluira
algo para implementar aplicaciones distribuidas en forma transparente.

Algo asi como un WCF del sub-desarrollo.. ;-)



WCF esta orientado a programación basada en atributos. La programación
basada en atributos se consigue gracias a reflection. Luego, la declaración
" - No usamos reflection" es falsa!




WCF también usa archivos de configuración XML
Respuesta Responder a este mensaje
#20 Daniel A. Calvin
20/06/2006 - 19:58 | Informe spam
Hola

Posiblemente me exprese mal.
Hay mappers o facdes que se encargan de la persistencia, las entidades no
saben absolutamente nada de recuperarse o persistirse.

Daniel A. Calvin
MCP


"Vyacheslav Popov" escribió:

>> NHibirnate, ObjectMapper.Net, etc..?
> Creo que hay varias diferencias, no hay que luchar con los archivos de
> mapeo, cripticos muchas veces y que la cosa trata de ir mas alla de la
> capa de datos.
> Con Cooperator podes bindear una coleccion de clientes a una DataGridView
> y tratarla en tiempo de diseño, es totalemente tipado.
> Es una de las ventajas.
> Y pese a ser tipado, tarbaja con transaciones que resuelven colaboraciones
> entre objetos de distinto tipo.

¿Entonces, la responsabilidad de hacer persistente a un objeto no se
delegará a la capa de datos sin el propio objeto del dominio será
responsable de hacerse persistente?



Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida