Sr's. Gurus: Entidades??

Una apreciaón, al escribir un archivo fuente de vb o c# si el código
contiene errores (no hace falta que me de código perfecto) los errores van a
saltar en tiempo de compilación y podré modificarlo, de este modo creo que
se ahorra tiempo, de no ser así por favor alfredo o el que sea que me
corrija!!

Como ves no pretendo hacer clases que sean directamente compilables,
ojalá!!, pero sí me de un bosquejo lo más parecido a como debiera quedar

On Thu, 28 Oct 2004 02:11:26 +0200, "Kravek" <rubengARROBAkailea4.net>
wrote:

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

Delphi también tiene sus propios DataSet, que se llaman igual.
PowerBuilder tiene algo parecido, ADO tiene los recordset, etc.

Tienes algo parecido en casi cualquier lenguaje y plataforma.

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

Un diseño debe de tener en cuenta las características de la plataforma
y los recursos disponibles, para aprovecharlos.

Otra cosa es el análisis.

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?

Un montón.

Esa es la consecuencia directa y la prueba de lo mal diseñado que
está.

Por supuesto si te refieres a que quizás le falten opciones pues yo para lo
que lo uso me vale pero puede ser

Lo que le falta es poder hacer lo mismo, pero con una pequeña fracción
del código que se necesita ahora.

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

Pues por que en muchas cosas ha sido un cambio a peor.

Y las cosas aun pueden ir a peor. Parece que la tontería del
ObjectSpaces se va a incluir en LongHorn. Espero que nunca lleguen a
sacarlo.

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

Pues a mi me pasa todo lo contrario. Tengo muy claro como
reimplementar ADO.NET, pero no tengo nada claro como se podría
remendar con generación automática de código.

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

Pero esto es exactamente lo contrario de lo que hay que hacer. Lo que
hay que hacer es poder conectar un formulario a un conjunto de tablas
con el mínimo esfuerzo posible y sin tener que crear ninguna clase
superflua. Algo parecido a como se hace con Delphi.

Las entidades se deben de definir en un solo sitio, y ese sitio es la
base de datos.

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

Eso se puede hacer dinámicamente. No hace falta generar código. Además
así la aplicación se podría adaptar a muchos cambios en el diseño
lógico de la base de datos sin necesidad de recompilación.

Como ves el resto del código es muy repetitivo y no veo manera de avitarlo
mediante un mejor diseño

Pues fíjate en Delphi. Con Delphi se puede hace una aplicación
sencilla sin escribir ni una linea de código.

Lo que hay que conseguir es poder hacer más cosas de esta forma y sin
problemas de rendimiento y escalabilidad, y esto es algo que se puede
conseguir perfectamente con un buen diseño.

¿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

No te entiendo muy bien, las clases y métodos para "rescatar datos" de
ADO.NET son SqlReader y SqlConnection, y si son parecidas a las clases
de otras plataformas, pero además de traer datos hay que presentarlos,
manipularlos y recogerlos, y ahí es donde falla ADO.NET

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.

Por lo que dices parece que estás gestionando las bases de datos desde
la aplicación, en lugar de hacerlo utilizando un SGBD. Esto es un
antipatrón muy conocido y de los que tienen peores consecuencias.

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

¡Que putada!

Ayer funcionaba, no se lo que le pasa.

Por suerte tenemos la caché del Google:

http://www.google.com/search?q=cache:LRcuw6gsiWcJ:c2.com/cgi/wiki%3FCodeGenerationIsaDesignSmell+CodeGenerationIsaDesignSmell&hl=es

En wiki hay mucha información interesante.

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;)

Pues te recomiendo ampliar tu formación en el campo de las bases de
datos.

En esta página hay libros y artículos muy buenos:

www.dbdebunk.com


Saludos

On Thu, 28 Oct 2004 14:31:55 +0200, "Kravek" <rubengARROBAkailea4.net>
wrote:

Una apreciaón, al escribir un archivo fuente de vb o c# si el código
contiene errores (no hace falta que me de código perfecto) los errores van a
saltar en tiempo de compilación

Solo los errores sintácticos.

Como ves no pretendo hacer clases que sean directamente compilables,
ojalá!!, pero sí me de un bosquejo lo más parecido a como debiera quedar

El problema es que vas a generar un código que no aporta ningún valor.


Saludos

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.

Y el acceso es igual (dentro de cada lenguaje) por eso tengo unas clases con
los métodos necesarios para facilitar el trabajo. Habái pensado que mi
aplicación (si al final la llevo a cabo...) podría copiar (no interpretar)
esas clases en el proyecto

Me refiero que Sólo en .Net existen los dataset

Delphi también tiene sus propios DataSet, que se llaman igual.
PowerBuilder tiene algo parecido, ADO tiene los recordset, etc.

De delphi no tengo ni idea :p, PowerBuilder si lo tiene es porque hay unas
clases que lo encapsulan (y a lo mejor son hasta macros) y lo de los
recordset si lo conocía y aunque mucho menos también hay que repetir código

Tienes algo parecido en casi cualquier lenguaje y plataforma.

Con sus pequeñas diferencias pero te doy la razón conceptualmente son
iguales

Un diseño debe de tener en cuenta las características de la plataforma
y los recursos disponibles, para aprovecharlos.

Otra cosa es el análisis.

Efectivamente te doy toda la razón me equivoqué me refería al análisis lo
que pasa que normalmente plasmo casi directamente el análisis en la
implementación (hoy por hoy eso me ahorra tiempo y mis aplicaciones no son
tan concurrentes como para no poder permitir ese desperdicio de recursos)

Esa es la consecuencia directa y la prueba de lo mal diseñado que
está.

Otra cosa en la que estoy de acuerdo contigo;)

Lo que le falta es poder hacer lo mismo, pero con una pequeña fracción
del código que se necesita ahora.

Otro punto en el que estamos de acuerdo;)

Pues por que en muchas cosas ha sido un cambio a peor.

Aún no tengo la suficiente experiencia como para poder juzgarlo pero me temo
que como lo uso (o para lo que lo uso) estoy emepzando a pensar lo mismo que
tú... una arquitectura demasiado compleja

Y las cosas aun pueden ir a peor. Parece que la tontería del
ObjectSpaces se va a incluir en LongHorn. Espero que nunca lleguen a
sacarlo.

Que es eso?esta noche buscaré algo de información y ya comentaré luego;)

Pues a mi me pasa todo lo contrario. Tengo muy claro como
reimplementar ADO.NET, pero no tengo nada claro como se podría
remendar con generación automática de código.

Aunque sea para implementar los dataset tipados...

Pero esto es exactamente lo contrario de lo que hay que hacer. Lo que
hay que hacer es poder conectar un formulario a un conjunto de tablas
con el mínimo esfuerzo posible y sin tener que crear ninguna clase
superflua. Algo parecido a como se hace con Delphi.

No conozco delphi :( pero por lo que comentas en cuanto saquen una version
de Delphi .Net la miraré
Ya pero mientras esta situación no cambie no veo otra manera de hacerlo

Las entidades se deben de definir en un solo sitio, y ese sitio es la
base de datos.

Y en mi programa no deberé tener una clase equivalente a esa entidad??o
dices de tratar los datos de manera inconexa sin estar agrupado en ningún
objeto?

Eso se puede hacer dinámicamente. No hace falta generar código. Además
así la aplicación se podría adaptar a muchos cambios en el diseño
lógico de la base de datos sin necesidad de recompilación.

Sí tienes razón se puede hacer en tiempo de ejecución pero si se hace en
tiempo de compilación el rendimiento mejora e incluso podría incluir esas
select, insert y demás dentro de la base de datos.

Efectivamente mi solución tiene el problema de la recompilación pero quizás
con sustituir algunas dll podría arreglarse (no evita el problema pero lo
minimiza)

Como ves el resto del código es muy repetitivo y no veo manera de avitarlo
mediante un mejor diseño

Lo que hay que conseguir es poder hacer más cosas de esta forma y sin
problemas de rendimiento y escalabilidad, y esto es algo que se puede
conseguir perfectamente con un buen diseño.

Ok, touche! eso siempre es posible aunque yo no de más no significa que mi
solución sea la mejor

¿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

No te entiendo muy bien, las clases y métodos para "rescatar datos" de
ADO.NET son SqlReader y SqlConnection, y si son parecidas a las clases
de otras plataformas, pero además de traer datos hay que presentarlos,
manipularlos y recogerlos, y ahí es donde falla ADO.NET

A eso me refiero unas pequeñas clases que recojan los datos y lo metan en
los objetos que los manipulen y luego regresen los datos a la BBDD
Aunque creo que mediante DataBindings algo se puede arreglar (estoy
investigandolo)

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.

Por lo que dices parece que estás gestionando las bases de datos desde
la aplicación, en lugar de hacerlo utilizando un SGBD. Esto es un
antipatrón muy conocido y de los que tienen peores consecuencias.

No he terminado de leerlo entero porque me tengo que ir ahora a clase pero
he leído la mitad y me dice que como yo pretendo automatizar mi código "no
smell", me explico...

No es para automatizar TODO el código, sólo pretendo que me de esqueletos de
clases similares (luego debo ya particularizar)
Quiero usarlo tipear FUERTEMENTE por ejemplo con clases de colección
Si hago cambios en el diseño ´las clases generadas por cuestiones de
tipificación podría quitarlas y volver a generarlas, las de los esqueletos
no, pero esos esqueletos serían para implementar patrones de diseño
principalmnete (alguna clase no pero bueno gran parte sí)

Por suerte tenemos la caché del Google:

http://www.google.com/search?q=cache:LRcuw6gsiWcJ:c2.com/cgi/wiki%3FCodeGenerationIsaDesignSmell+CodeGenerationIsaDesignSmell&hl=es

San Google :D

En wiki hay mucha información interesante.

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;)

Pues te recomiendo ampliar tu formación en el campo de las bases de
datos.

En esta página hay libros y artículos muy buenos:

www.dbdebunk.com

Por supuesto que trataré de ampliar mis conocimientos siguiendo tu consejo
pero te agradecería que me resolvieras una duda pues no entiendo lo que
dices de los SGBD.

Quiero insertar un pedido entero en la BBDD o no insertar nada, los campos
serían nombre cliente, nº de pedido y fecha. Los campos de cada línea del
pedido sería nombre producto, id del producto, cantidad y precio unitario.

¿Cómo puedo insertar todo eso en la bbdd y encima obtener el nº del pedido
(el de la factura)?yo para eso necesito una clase pedido, otra lineapedido,
sus correspondientes tablas, abrir una transacción, llamar a la función de
inserción de la clase pedido y luego llamar N veces a la función de insertar
líneas para luego cerrar la transacción. Todo ese código yo lo aparto en una
clase aparte por legibilidad.

Si se puede hacer mediante un SP como sería?te agradecería que pusieras el
código o un bosquejo.

Espero no abusar demasaido de tu ayuda

On Thu, 28 Oct 2004 16:50:55 +0200, "Kravek" <rubengARROBAkailea4.net>
wrote:

No conozco delphi :( pero por lo que comentas en cuanto saquen una version
de Delphi .Net la miraré

Hace tiempo que sacaron una versión para .NET y acaban de sacar la
segunda.

Las entidades se deben de definir en un solo sitio, y ese sitio es la
base de datos.

Y en mi programa no deberé tener una clase equivalente a esa entidad??

¡Exacto!

Hay muchas razones por las que no debe de haberla.

Una tabla SQL es una variable de tipo colección, se parece un poco a
un "array" de C#, y es totalmente diferente de una clase que es un
tipo de datos.

Por ejemplo una tabla de clientes representa al conjunto de clientes
de una empresa en un momento dado, es decir varía con el tiempo. Pero
una clase Cliente es estática, siempre es igual. Es decir, que de
equivalentes no tienen nada.

Para representar una tabla de clientes con la clase Cliente lo que
necesitas es una variable de tipo colección de Cliente que va a ser
típicamente una lista enlazada unidimensional.

O sea que has empleado un montón de trabajo para conseguir algo mucho
menos potente y manejable de lo que ya tenías: la tabla.

Las tablas se pueden unir, proyectar, juntar, resumir, etc utilizando
sencillas instrucciones SQL. Con la lista de objetos Cliente no se
puede hacer nada de eso y hay que hacerlo todo a pedales a base de
mucho código.

Cuando insertas un registro en la tabla de clientes, el SGBD
automáticamente va a comprobar todas las restricciones de integridad
(reglas de negocio): claves candidatas, claves externas, aserciones,
triggers, etc. Cuando creas un nuevo objeto Cliente y lo añades a la
colección te toca hacer todas las comprobaciones a pelo.

Es más los SGBD se crearon precisamente para poder eliminar este tipo
de entidades de las aplicaciones.

Imagínate que tienes que hacer un informe de rentabilidad. Si usas las
clases propias vas a tener que traerte prácticamente todos los
registros de la base de datos, ir recorrendolos todos, ir relacionando
los datos de las distintas tablas e ir acumulando valores. Un trabajo
de chinos que va a provocar un montón de tráfico de red.

Si lo haces con SQL simplemente tienes que especificar el resultado
que deseas y el SGBD se encarga de todo lo demás enviando a la
aplicación los resultados ya listos para presentar.

Otro ejemplo: imagínate que tienes que subirle el sueldo un 5% a los
empleados de paises de la Union Europea con más de 10 años de
antigüedad. Con los objetos propios tendrías que traerte todos los
registros de empleados mirar la antiguedad y el pais, comprobar si el
pais es de la UE, subirles un 5% y después enviar una orden de
actualización al SGBD. Si lo haces en SQL le mandas una linea de nada
al servidor, este se ocupa de todo y lo hace muchísimo más rápido sin
apenas tráfico de red.

Vamos, que con lo de los objetos propios el volumen de código se puede
multiplicar tranquilamente por 5 o por 10 y además puede ir mucho más
lento. Y si quieres acelerarlo a base de cachés y cosas de esas pues
otra vez a escribir un montón de código, y tampoco vas a conseguir
maravillas.

o
dices de tratar los datos de manera inconexa sin estar agrupado en ningún
objeto?

Esto no lo entiendo.

Eso se puede hacer dinámicamente. No hace falta generar código. Además
así la aplicación se podría adaptar a muchos cambios en el diseño
lógico de la base de datos sin necesidad de recompilación.

Sí tienes razón se puede hacer en tiempo de ejecución pero si se hace en
tiempo de compilación el rendimiento mejora e incluso podría incluir esas
select, insert y demás dentro de la base de datos.

El rendimiento no lo es todo. Hay que buscar un equilibrio entre
esfuerzo y rendimiento. Si para lograr un 5% más de rendimiento tienes
que trabajar el triple está claro que no vale la pena. Es mucho más
rentable gastarte 4 duros más en un equipo más rápido.

Efectivamente mi solución tiene el problema de la recompilación pero quizás
con sustituir algunas dll podría arreglarse (no evita el problema pero lo
minimiza)

Ya, lo que pasa es que esto no es nada comparado con el problema de la
gestión de la información de forma procedimental desde las
aplicaciones.

Lo que hay que conseguir es poder hacer más cosas de esta forma y sin
problemas de rendimiento y escalabilidad, y esto es algo que se puede
conseguir perfectamente con un buen diseño.

Ok, touche! eso siempre es posible aunque yo no de más no significa que mi
solución sea la mejor

Lo que pasa es que los problemas de los "objetos propios" hacen que no
sea una solución aconsejable.

Si intentases implementar por ejemplo un sistema de gestión de
almacenes o gestión comercial minimamente realista, utilizando las
listas de objetos en memoria te darías cuenta enseguida de lo
engorroso que es.

Estas son cosas muy trilladas. Lo de gestionar los datos desde las
aplicaciones utilizando listas en memoria es una cosa muy antigua que
se dejó de hacer hace décadas por todos los problemas que daba.

La solución a estos problemas fue la aparición de los Sistemas de
Gestión de Bases de Datos.

Gestionar los datos desde la aplicación y usar un SGBD solo como
mecanismo de persistencia es como usar un coche para guardar la
chaqueta e ir detrás empujándolo.

En esta página hay libros y artículos muy buenos:

www.dbdebunk.com

Por supuesto que trataré de ampliar mis conocimientos siguiendo tu consejo

Pues estos libros son lo mejor que hay con diferencia para aprender
sobre bases de datos. Son tan buenos que hacen malos a casi todos los
demás.

Hay una edición en español llamada "Introducción a los Sistemas de
Bases de Datos", que es el mejor para empezar y sale mucho más barata
que la edición en inglés, y además es fácil de encontrar en cualquier
librería especializada.

http://www.agapea.com/Introduccion-...11521i.htm

Quiero insertar un pedido entero en la BBDD o no insertar nada, los campos
serían nombre cliente, nº de pedido y fecha. Los campos de cada línea del
pedido sería nombre producto, id del producto, cantidad y precio unitario.

¿Cómo puedo insertar todo eso en la bbdd y encima obtener el nº del pedido
(el de la factura)?

Si es un pedido que está fijo en algún sitio ejecutas un script SQL
con los insert y luego haces una consulta para obtener los números de
factura que supongo que será un simple campo autoincrementado.

En caso de que el número de factura sea más complejo lo puedes
calcular con un "trigger".

En caso de que sea una aplicación con una interfaz gráfica solo
necesitas asociar las tablas de la base de datos a los controles del
formulario y listo. Eso en Delphi se hace muy fácilmente.

yo para eso necesito una clase pedido, otra lineapedido,
sus correspondientes tablas, abrir una transacción, llamar a la función de
inserción de la clase pedido y luego llamar N veces a la función de insertar
líneas para luego cerrar la transacción.

Yo eso lo hago sin una linea de código :)

Si se puede hacer mediante un SP como sería?te agradecería que pusieras el

Los SP son la peor forma de implementar algo en un SGBD, se deben de
usar solo cuando no haya una forma declarativa de hacerlo. Para hacer
lo que dices no veo necesidad de usar SPes, excepto quizás para
generar el número de factura, ya que los "triggers" son simplemente un
caso especial de SPes.

Espero no abusar demasaido de tu ayuda

No te preocupes.


Saludos