Cooperator framework

[Table(Name="Cliente")]
public class Cliente

Ya me esta gustando más ;)

Otra cosa, ¿supongo que la descripción de objetos se hará con atributos?
¿como en DLINQ?

//Ejemplo de DLINQ:

[Table(Name="Cliente")]
public class Cliente
{
[Column(DbType="nvarchar(32) not null", Id=true)]
public string Nombre;
[Column]
public int Edad;
}

Saludos.


"Daniel A. Calvin" escribió en el
mensaje news:
> 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?
>>
>>
>>

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




"Daniel A. Calvin" escribió en el mensaje
news:%
> 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
>

Entonces, si no se utiliza reflection habrá que crear, como mínimo, para
cada una de las clases de dominio los métodos CRUD en la fachada de
persistencia, crear un adaptador correspondiente y pasarle el control.

Si es así, con un poco de reflection se podría ahorrar muchas líneas de
código. ¿no?

Saludos.

"Daniel A. Calvin" escribió en el
mensaje news:
> Hola Lluís
>
> Supongamos que tienes que manejar Facturas de ventas o Remitos o cualquier
> documento del tipo maestro detalle.
>
> Cooperator te permite definir objetos del dominio.
>
> Tendrás una Facade que te entregara esos objetos completos o parcialmente
> segun lo necesites, pero como una entidad única.
>
> Y si necesitas una lista de ellos te brindará una coleccion de esos
> objetos.
>
> Tu esquema con datasts es datacentrico esto es mas OOP.
>
>
>
> Daniel A. Calvin
> MCP
>
>
> "Lluís Franco" escribió:
>
>>
>> :-)
>> Hola Daniel,
>>
>> Una estupenda iniciativa!
>> Ardo en deseos de empezar a probarlo.
>> Sólo una pregunta: Si no utilizáis DataSets ¿cómo manejáis las
>> estructuras
>> maestro/detalle? Sobre todo la parte de las actualizaciones...
>>
>> Saludos,
>>
>> Lluís Franco i Montanyés
>> [MS-MVP-MCP Visual Basic]
>> Web: http://www.uyssoft.com
>> Blog: http://msmvps.com/lfranco
>> (Guía de netiquette del foro)
>> http://www.uyssoft.com/MSNews.aspx?sm
>> FIMARGE, S.A.
>> Principat d'Andorra
>>
>> Tel.: +376 805 100
>> Fax: +376 824 500
>> Mi Perfil MVP en:
>> https://mvp.support.microsoft.com/profileaa1615-1a2f-4202-bc3f-aec297d967d2
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
>> derecho
>>
>>
>>
>>

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

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

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?

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