Sr's. Gurus: Entidades??

Y por qué no implementar esos dataset tipados para que se puedan cargar a
partir de nuestros objetos propios? es decir clases de interfaz.

Y para generar esas clases... qué tal un pequeño programa que procese
plantillas?yo estoy creando uno (como proyecto de clase) y ahora es capaz de
ahorrarme muuucho código y eso que no tiene casi ninguna de las
características de las que le quiero dotar.

Por ejemplo para crear clases de colecciones TIPADAS que "envuelvan" mis
objetos, usando un poco de reflectividad es capaz de crearme una para cada
una de las clases del proyecto dela capa de entidad que NO sea una
excepción. Como es un procesador de plantillas pues esa es una de las
aplicaciones...

El objetivo de este programa es que sea PARECIDO a CodeSmith
(http://www.ericjsmith.net/codesmith/) pero que haga lo mismo para las
clases que YO quiera de mi proyecto con las plantillas que YO quiera y no
como en CodeSmith que tengo que ejecutar cada plantilla para cada clase...

Eso sí, el estado de este proyecto es casi nulo (estoy empezando el curso
:D) y sólo me hace sustituciones (eso sí tantas veces como ahga falta) y no
me "preprocesa" código .Net

Si alguien está interesado en este desarrollo que me lo diga y le paso el
código fuente así como todas las actualizaciones que vaya haciendo, ahora
bien, me gustaría que a todo aquel que le enviara el código me ayudara un
poquito aunque sea criticandome el código fuente o sugiriendome mejoras, o
dandome bugs o dandome trozos de código paraimplementar tal función que no
tiene, o lo que se le ocurra...

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 27 Oct 2004 08:30:54 +0200, "Alex Bibiano"
wrote:

Bajo mi modesta opinión personal, he programado antes en Java, y el tema
de
los objetos me gusta más, lo encuentro más organizado, más extensible y
más
controlable, pero reconozco que tal como está montado el Visual Studio,
trabajar con datasets (especialmente los tipados) és mucho más rápido.

Es decir, que es mucho mejor.

Estoy de acuerdo, aunque todavía podría ser mucho mejor si los
datasets estuviesen bien diseñados.

De
todas formas, con la próxima versión esto creo que cambiará, ya que los
genéricos y unas cuantas utilidades para enlazar objetos de usuarios a
controles de forma visual, harán que sea prácticamente igual de sencillo
trabajar con objetos de usuario que con datasets.

No estoy nada de acuerdo.

Actualmente sin embargo,
hay que escribir bastante código en nuestras clases para poder implementar
la misma funcionalidad que un dataset (editar en un grid, ordenar lista de
objetos, ...)

Es decir, que es un práctica antieconómica que debemos evitar.


Saludos

On Wed, 27 Oct 2004 20:38:35 +0200, "Kravek" <rubengARROBAkailea4.net>
wrote:

Y por qué no implementar esos dataset tipados para que se puedan cargar a
partir de nuestros objetos propios? es decir clases de interfaz.

Pues por que si ya tenemos los datasets, ya no necesitamos "nuestros
objetos propios".

No se debe añadir complejidad innecesaria a las aplicaciones.

El objetivo de este programa es que sea PARECIDO a CodeSmith
(http://www.ericjsmith.net/codesmith/) pero que haga lo mismo para las
clases que YO quiera de mi proyecto con las plantillas que YO quiera y no
como en CodeSmith que tengo que ejecutar cada plantilla para cada clase...

Eso sí, el estado de este proyecto es casi nulo (estoy empezando el curso
:D) y sólo me hace sustituciones (eso sí tantas veces como ahga falta) y no
me "preprocesa" código .Net

En mi opinión, un proyecto que si podría ser interesante es volver a
hacer ADO.NET, pero bien hecho.


Saludos

Pues por que si ya tenemos los datasets, ya no necesitamos "nuestros
objetos propios".

No se debe añadir complejidad innecesaria a las aplicaciones.

Si bien es cierto que puede resultar complicado (o al menos más que si se
usan los datasets de .Net) también es cierto que pueden ayudar a
entendermejor la aplicación y si se programa bajo diferentes lenguajes según
el proyecto (en mi caso normalmente .Net, Java y C++ "normal") puede ser
interesante no ligar los diseños de la aplicación a una plataforma concreta.
Pero como bien dices tampoco se debe añadir complejidad innecesaria SALVO
que haya razones en cuyo caso puede ser si no necesaria lógica.

Otro motivo es si vienes de otros lenguajes en lo que te adaptas... o por
motivos docentes

En mi opinión, un proyecto que si podría ser interesante es volver a
hacer ADO.NET, pero bien hecho.

Hombre creo que eso queda algo lejos de un proyecto de una asignatura (ni
siquiera de un trabajo de fin de carrera) ... :D
Pero si dices los fallos, y los posteas al feedback de microsoft, quizás en
futuras versiones lo arreglen, y si los que los leamos nos parecen también
fallos podemos también postearlo como feedback, y si somos muchos lo
arreglaran ;)

En cualquier caso de momento para lidiar con ADO .Net como veo que un gran
problema es que se debe repetir muucho código, sino igual sí parecido, pues
un programa (espero poder en un futuro integrarlo en el IDE como un Addin)
que automatice no estaría mal.

On Wed, 27 Oct 2004 22:17:31 +0200, "Kravek" <rubengARROBAkailea4.net>
wrote:

No se debe añadir complejidad innecesaria a las aplicaciones.

Si bien es cierto que puede resultar complicado (o al menos más que si se
usan los datasets de .Net) también es cierto que pueden ayudar a
entendermejor la aplicación y si se programa bajo diferentes lenguajes según
el proyecto (en mi caso normalmente .Net, Java y C++ "normal") puede ser
interesante no ligar los diseños de la aplicación a una plataforma concreta.

Pues no te entiendo muy bien.

Imaginemos que tenemos un sistema de información con un SGBD y
aplicaciones escritas en distintos lenguajes y para distintas
plataformas.

Las aplicaciones .NET pueden usar datasets de ADO.NET, las de Java
pueden usar JDBC, y las de C++ pueden usar ODBC, o el viejo ADO.

En mi opinión, un proyecto que si podría ser interesante es volver a
hacer ADO.NET, pero bien hecho.

Hombre creo que eso queda algo lejos de un proyecto de una asignatura (ni
siquiera de un trabajo de fin de carrera) ... :D

Efectivamente, sobre todo teniendo en cuenta que el principal defecto
de ADO.NET es que es muy simplista. Hacerlo bien costaría bastante más
de lo que les costó hacerlo mal.

Yo estaba pensando en un proyecto del estilo del proyecto Mono, no en
un trabajo de una asignatura. Pero francamente no tengo ninguna
esperanza de que se realice.

Pero si dices los fallos, y los posteas al feedback de microsoft, quizás en
futuras versiones lo arreglen, y si los que los leamos nos parecen también
fallos podemos también postearlo como feedback, y si somos muchos lo
arreglaran ;)

El problema es que no son pequeños fallos, son fallos fundamentales de
análisis. Habría que volver a empezar desde el principio, y creo que
el "feedback" de Microsoft no es para eso.

En cualquier caso de momento para lidiar con ADO .Net como veo que un gran
problema es que se debe repetir muucho código, sino igual sí parecido, pues
un programa (espero poder en un futuro integrarlo en el IDE como un Addin)
que automatice no estaría mal.

Ya, pero automatizarlo todo costaría aun más trabajo que tirar con
ADO.NET y volverlo a hacer, y la segunda solución quedaría mucho
mejor.

La generación automática de código casi siempre es una consecuencia de
un mal diseño. Si la generación de código se puede automatizar quiere
decir que ese código se podría haber evitado.

http://c2.com/cgi/wiki?CodeGenerati...esignSmell

El mejor código no es el código que podemos generar automáticamente,
el mejor código es el código que no existe, ese nunca da problemas :)

Como decía un antiguo jefe mio: un programa está acabado cuando no
queda nada que añadir, ni nada que borrar.


Saludos

Si bien es cierto que puede resultar complicado (o al menos más que si se
usan los datasets de .Net) también es cierto que pueden ayudar a
entendermejor la aplicación y si se programa bajo diferentes lenguajes
según
el proyecto (en mi caso normalmente .Net, Java y C++ "normal") puede ser
interesante no ligar los diseños de la aplicación a una plataforma
concreta.

Pues no te entiendo muy bien.
Imaginemos que tenemos un sistema de información con un SGBD y
aplicaciones escritas en distintos lenguajes y para distintas
plataformas.

Las aplicaciones .NET pueden usar datasets de ADO.NET, las de Java
pueden usar JDBC, y las de C++ pueden usar ODBC, o el viejo ADO.

Me refiero que Sólo en .Net existen los dataset y si quiero hacer un diseño
de la aplicación sin saber a priori que plataforma de implementación usaré,
no debo usar ya tecnologías específicas

Efectivamente, sobre todo teniendo en cuenta que el principal defecto
de ADO.NET es que es muy simplista. Hacerlo bien costaría bastante más
de lo que les costó hacerlo mal.

A mi me parece demasiado enrevesado... ¿Para rescatar un simple dato cuantas
líneas hay que escribir?
Por supuesto si te refieres a que quizás le falten opciones pues yo para lo
que lo uso me vale pero puede ser

Yo estaba pensando en un proyecto del estilo del proyecto Mono, no en
un trabajo de una asignatura. Pero francamente no tengo ninguna
esperanza de que se realice.

Bueno ya has visto el cambio de ADo a ADO.Net, ¿por qué ser pesimista?

El problema es que no son pequeños fallos, son fallos fundamentales de
análisis. Habría que volver a empezar desde el principio, y creo que
el "feedback" de Microsoft no es para eso.

Te doy totalmente la razón si el fallo es que está mal diseñado ya entonces
es distinto;)

Ya, pero automatizarlo todo costaría aun más trabajo que tirar con
ADO.NET y volverlo a hacer, y la segunda solución quedaría mucho
mejor.

No sabría por donde empezar reimplementando PERO más o menos sé por donde
empezar para automatizar código y no es tanto trabajo como parece...

Supongamos el siguiente contexto: si para cada atributo "simple" de mi
objeto tengo un atributo de igual nombre en una tabla con el mismo nombre
que la clase de mi objeto. Podría hacer: una plantilla que rescatara de base
de datos un objeto determinado (por ejemplo buscando por el Id).

-Para ello necesito poder analizar la estructura de la base de datos para o
bien generar el string con el select o bien crear automáticamente la vista.
-Asignar cada atributo de la base de datos a cada atributo del objeto, para
esto tendría que usar reflectividad.

Como ves el resto del código es muy repetitivo y no veo manera de avitarlo
mediante un mejor diseño (debo abrir los connection y el resto de objetos
queme guste usar, inicializarlos...)

¿Todas las clases (y/o métodos) para rescatar de base de datos no tienen un
código muy parecido? yo creo que sí y no puedo evitarlo, de poderse evitar
me gustaría que me dieras una solución y pienso en otro proyecto más útil

La generación automática de código casi siempre es una consecuencia de
un mal diseño. Si la generación de código se puede automatizar quiere
decir que ese código se podría haber evitado.

Hombre por ejemplo con mi programa tal cual está (sólo puedo sustituir
literales), puedo crear automáticamente con una plantilla (que me ha costado
muy poquito hacerla) clases de colección para todas las clases de un
proyecto.

Quizás en el primer proyecto no note ventajas pero cuando tenga que hacer el
próximo seguro que sí!! (una vez haces una plantilla, tarea muy fácil, la
dificultad radica en el "parser/compilador", la puedes usar para futuros
proyectos)

http://c2.com/cgi/wiki?CodeGenerati...esignSmell

El link me pone forbidden :( por favor indicame como llegar a él ya que los
temas de diseño me interesan MUCHO

El mejor código no es el código que podemos generar automáticamente,
el mejor código es el código que no existe, ese nunca da problemas :)

Totalmente de acuerdo pero creo que hay código inevitable o al menos yo no
sé como no escribirlo;)

Como decía un antiguo jefe mio: un programa está acabado cuando no
queda nada que añadir, ni nada que borrar.

Uy! no, que si es perfecto no podemos cobrar mantenimiento :DD