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

#36 Daniel A. Calvin
20/06/2006 - 21:16 | Informe spam
Cooperator te generará los Mapper y/o Facades, las entidades del dominio,
incluidas las agregaciones que definas, los store procedures y una cantidad
de artefactos para utilizar esos mappers y entidades abstrayendote de los
datos.

Te arma las transacciones en memoria para hacer tus operaciones totalmente
ohesivas.

Al ser tipado, las entidadse, te permite bindear a los contrles net en
tiempo de diseño y hacer las personalizaciones que creas necesarias.

Resumiendo, no hace nada que no puedas escribir vos, solo te evita hacerlo y
te propone un esquema probado.

Adios
Daniel A. Calvin
MCP


"Vyacheslav Popov" escribió:

Daniel, perdona por el mal entendido, pero sigo sin comprender, que es lo
que hace Cooperator.

¿Te importa poner un ejemplo?

Saludos.

"Daniel A. Calvin" escribió en el
mensaje news:
> Hola, lamento que llegues a una conclusion tan apresurada.
> WCF te permite definir el transporte de objetos, abstaryendote de detalles
> tales como protocolos y una serie de detalles adicionales.
>
> Cooperator no utiliza reflection para ninguna de las cuestiones que
> mencione
> en el email inicial.
>
> Que WCF la utilice no quiere decir que lo dicho antes sea falso.
>
> De todas formas si incluimos el layer para implementar aplicaciones
> distribuidas usamos reflection para crear el transporte.
> Solo para eso, no invocamos metodos ni propiedades por reflection.
> Todo en el framework es totalmente tipado.
>
> La creación de la capa de transporte usa reflection solo si queres que la
> misma sea configurable y solo la usa para instanciar ese objeto.
>
> Y te invito a que tu frase:
>> " - No usamos reflection" es falsa!
>
> la publiques cuando veas el producto funcionando.
>
> No es nuestra intención mentir ni mucho menos.
>
> Gracias
>
> Daniel A. Calvin
> MCP
>
>
> "Vyacheslav Popov" escribió:
>
>> >> ¿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
#37 Vyacheslav Popov
20/06/2006 - 21:17 | Informe spam
Seguro que con reflection puedes ahorrate muchas lineas de código.

Pero como esas lineas de código las escribe Cooperator no nos preocupa.



Una cosa es que Cooperator ayuda y otra es depender de él (aunque para
primera versión podría justificarse).

Todo eso que mencionas Cooperator lo necesita, pero no lo escribe el
programador, lo escribe el solito.
Ese fue el enfoque que pretendimos darle, fue nuestro objetivo.
Puede no gustarte por supuesto.



Lo voy pillando, el Cooperator crea un ORM personalizado. ¿no?

Pero la realidad es que escribis muy poco, todo ese código pesado lo
escribe
cooperator y tu ni te enteras. Solo invocas el mapper correspondiente.

Por ejemplo:

dim objClientes as ClientesList = ClientesMapper.GetList(new
ClienteFinder.TraerPorLocalidad( localidad))

( Si trabajaramos por reflection esta linea de codigo no sería tan clara
para quien no conoce la aplicación )



Estoy de acuerdo, es mucho más claro.
Respuesta Responder a este mensaje
#38 Vyacheslav Popov
20/06/2006 - 21:29 | Informe spam
Perdona Daniel, no quería ofenderte...

Y sí me interesa, tal vez demasiado.

Saludos.

"Daniel A. Calvin" escribió en el
mensaje news:
Hola Vyacheslav Popov

Trato de responder todas las peguntas.
En un momento crei que tenías algún interes en que te cuente sobre la
iniciativa, ya no se que pretendes.

Que tengas un buen día.

Daniel A. Calvin
MCP


"Vyacheslav Popov" escribió:


"Alfredo Novoa" escribió en el mensaje
news:
> 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?

Me temo que sí.

> ¿Que ventaja tiene con respecto a aplicar estas operaciones
> algebraicas directamente sobre el SGBD?

Uyyyyy... no voy a responder a ésta pregunta ;)


Saludos.



Respuesta Responder a este mensaje
#39 Daniel A. Calvin
20/06/2006 - 21:34 | Informe spam
Interlineado:

Una cosa es que Cooperator ayuda y otra es depender de él (aunque para
primera versión podría justificarse).



No dependes de el, los scripts en base a los cuales se genera el código que
vas consumir son mantenibles por el usuario.
Podes crear tus propios scripts:
, te gusta vb.net crealos en vb.net
, te gusta c# crealos en c#
, te gusta j# crealos en j#

De lo que dependes es de la estructura base de Cooperator, lo ismo si usas
Ibatis, NHibernet, ORM.Net o cualquier framework.

La diferencia es que Cooperator te genera cosas que se utilizan mas allá d
la capa de datos.

otra es depender de él





Resumiendo no creo que se pueda depender menos de un framework que esto. La
única opción es nu usar nmingún framework.

Lo voy pillando, el Cooperator crea un ORM personalizado. ¿no?


Digamos que parte de lo que hace Cooperator es ORM.


Saludos
Daniel A. Calvin
MCP


"Vyacheslav Popov" escribió:

> Seguro que con reflection puedes ahorrate muchas lineas de código.
>
> Pero como esas lineas de código las escribe Cooperator no nos preocupa.

Una cosa es que Cooperator ayuda y otra es depender de él (aunque para
primera versión podría justificarse).

> Todo eso que mencionas Cooperator lo necesita, pero no lo escribe el
> programador, lo escribe el solito.
> Ese fue el enfoque que pretendimos darle, fue nuestro objetivo.
> Puede no gustarte por supuesto.

Lo voy pillando, el Cooperator crea un ORM personalizado. ¿no?

> Pero la realidad es que escribis muy poco, todo ese código pesado lo
> escribe
> cooperator y tu ni te enteras. Solo invocas el mapper correspondiente.
>
> Por ejemplo:
>
> dim objClientes as ClientesList = ClientesMapper.GetList(new
> ClienteFinder.TraerPorLocalidad( localidad))
>
> ( Si trabajaramos por reflection esta linea de codigo no sería tan clara
> para quien no conoce la aplicación )

Estoy de acuerdo, es mucho más claro.



Respuesta Responder a este mensaje
#40 Alfredo Novoa
20/06/2006 - 21:37 | Informe spam
On Tue, 20 Jun 2006 12:00:01 -0700, Daniel A. Calvin
wrote:

¿Que ventaja tiene con respecto a aplicar estas operaciones
algebraicas directamente sobre el SGBD?



No se trata de ventajas, se tarta de acceso, si estoy en un entorno remoto,
no puedo acceder a lso metodos CRUD del motor de base de datos.



¿Pero de que estás hablando?

Esta frase no tiene ningún sentido.

Yo te he preguntado sobre si se puede aplicar el álgebra de
operaciones de conjuntos de LINQ sobre vuestras colecciones, y en caso
afirmativo que es lo que se gana con este nuevo nivel de indirección.

En caso de que no se pueda, pues estaríais limitando drásticamente la
potencia de LINQ. Sería como construir una radio metiendo un televisor
dentro de una caja de madera.

Por otra parte tampoco me interesa llevar la logica de persistencia al
cliente.



¡Solo faltaría! De la persistencia ya se encarga el SGBD.

Toda la capa de negocio resuelve las colaboraciones, algunas clases que
componen la capa de negocio tienen contacto con la capa de datos.

El Cliente, ya sea viá capa de transporte, no en esta verison d cooperator,
o en forma directa, solo conoce la capa de negocios, el modelo de domio o los
procesos y entidades si lo prefieres.



http://en.wikipedia.org/wiki/Technobabble

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


Aqui vamos a tener algún problema.



Si, por que si no se puede hacer eso menuda porquería.

Está clarísimo que estais ofreciendo "aceite de serpiente".

http://daurmith.blogalia.com/historias/8893


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