Pregunta para Alfredo Novoa

Si quieres hacemos un debate sobre la generacion de codigo ?

Saludos,
Eugenio

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 7 Mar 2007 15:08:11 -0300, "Eugenio Serrano"
wrote:

Claro que hay codigo extra que no he puesto, ya que el mismo se genera
automaticamente, es decir no tengo que programarlo yo.

¿Has leido esto?

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

Lo que he escrito es lo unico que tengo que programar yo, lo demas se
genera
automaticamente.

En mi caso y en el de LinQ no hay necesidad de generar código.

Quiero saber todos los clientes que han comprado por lo menos un
artículo de cada durante este año.

Voy a cooperator Modeler, escribo el SELECT necesario y genero el modelo
de
nuevo.Esto me genera el Stored Procedure en la base de datos y un Metodo
en
el mapper que me devuelve una coleccion de los clientes que han comprado
por lo menos un articulo en el año. Solo con usar la herramienta me genera
tanto el procedimiento almacenado y el metodo en mi mapper para hacer la
consulta. Es decir, no tengo que escribir NADA mas.

Bueno, era un artículo de cada, pero es igual. Es decir que al final
quien resuelve toda la gestión de los datos es el SGBD, y Cooperator
Framework se parece un montón a usar DataSets tipados y es solo una
fina capa de comunicación dentro de las aplicaciones de presentación.

Por cierto, una vez por curiosidad se me ocurrió probar los datasets
tipados con una base de datos no muy compleja (un par de cientos de
tablas o así), y el VS2005 se me quedó cuajado varios minutos y me
generó más de 20 megas de código fuente (cientos de miles de líneas) y
más de 4 megas de código ejecutable que no hacía absolutamente nada, y
luego el IDE iba de pena. ¿Como resuelves eso?

Y para obtener esa informacion lo uso asi:

Dim misClientes as ClienteList >>ClienteMapper.GetClientesConMovimientos(2007)

Y listo, despues si quiere recorrer esos clientes hago asi:

For Each cliente As Cliente In misClientes
'Aqui hago lo que quiero con cada cliente..
cliente.Nombre
cliente.Edad
etc..
Next

No se para que podrías querer recorrer la lista. Si te traes todos los
datos ya masticados le enchufas la lista al grid o usas databindings y
listo. Para hacer databindings no hay ninguna necesidad de usar
datasets tipados ni colecciones de este tipo, te llega con una clase
genérica del estilo de DataTable, y te ahorras todo este follón y
engordar las aplicaciones con código que no aporta nada.

Sigo sin verle utilidad a todo esto, pero por lo menos no lo usas para
hacer las típicas atrocidades del OR Mapping. La gestión de los datos
la sigue haciendo el SGBD. Hacer estas consultas mediante código VB o
C# sería una locura.


Saludos

On Wed, 7 Mar 2007 18:59:28 -0300, "Eugenio Serrano [MVP]" <eserrano
{-AT-} solidqualitylearning.com> wrote:

Si quieres hacemos un debate sobre la generacion de codigo ?

No creo que haga falta. El mejor código es el que no existe, sea
generado o no.


Saludos

On Wed, 7 Mar 2007 18:58:34 -0300, "Eugenio Serrano [MVP]" <eserrano
{-AT-} solidqualitylearning.com> wrote:

cmd.Parameters["@p_name"].Value = custName;
cmd.Parameters["@p_birthdate"].Value = dateOfBirth;
cmd.Parameters["@p_city"].Value = cityName;

cmd.ExecuteNonQuery();

Que es más o menos igual de engorroso que con Cooperator Framework.

Falta muuuchisimo mas codigo... eso es solo para una tabla...

No falta casi nada, pero esto es una forma muy mala de programar.
Habría que hacerlo sin nada de código con databindings.

La orden tiene una cabecera y un detalle... Necesitas escribir muuuucho mas
codigo, mucho mas que mi ejemplo usando Cooperator.

Con Delphi haces eso y mucho más con cero líneas de código. Crear
órdenes de esa forma es una chapuza. Con datasets tipados también
puedes hacerlo con cero líneas de código.

http://www.intsight.com/whidbeydb/whidbey.html

De todas formas eso solo "resuelve" una pequeñísima parte de lo que es
una aplicación.

Ademas te falta el codigo para armar la conexion y para armar el comando...

Eso solo hay que hacerlo una vez y es muy sencillo.


Saludos

¿Has leido esto?

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

La generacion de codigo puede tener su complicacion si no puedes volver a
generar cuando hay cambios y te terminas despegando del modelo. Ahi
fracasaron la mayoria de las herramientas CASE.

En cooperator Modeler hemos resulto algunos de esos problemas haciendo lo
siguiente:

1) Que el modelo se guarda en un archivo .coop, que mantiene cual es el
modelo que quieres generar.
2) Por cada clases se generan 2 archivos que son clases parciales. Cuando tu
vuelves a re-generar el modelo por algun cambio, solo se vuelve a generar
uno de esos 2 archivos. En el otro es donde escribes tu personalizacion de
la clase, de esa forma se puede volver a generar todo el tiempo sin perder
nada.

Aunque no te guste, Visual Studio genera codigo en cantidad de lugares, al
solo pegar un control sobre un formulario se esta generando codigo, incluso
ASP.Net lo hace al compilar las paginas aspx, en los datasets, etc, etc,
etc...
El adminstrador de SQL genera codigo automaticamente cuando usas la
herraminta para hacer cualquier modifican sobre la base, imaginate de
escribir todo el codigo SQL a mano !!!

Con la generacion de codigo puedes multiplicar la productividad enormemente,
y dejar de trabajar en forma artesanal.
Al codigo generado no tienes que depurarlo porque ya fue lo suficientemente
probado.
Generas el codigo para las cosas repetitivas donde realmente no hace falta
materia gris para programarlo.
Usas las preciadas horas de un progamador para que piense en resolver el
verdadero problema y no en escribir Stored procedures y clases que se
repiten una y otra vez.

En todo proyecto existen cosas repetitivas y ahi el codigo generado es una
bendicion...

Por cierto, una vez por curiosidad se me ocurrió probar los datasets
tipados con una base de datos no muy compleja (un par de cientos de
tablas o así), y el VS2005 se me quedó cuajado varios minutos y me
generó más de 20 megas de código fuente (cientos de miles de líneas) y
más de 4 megas de código ejecutable que no hacía absolutamente nada, y
luego el IDE iba de pena. ¿Como resuelves eso?

A mi tampoco me gustan los datasets, con cooperator tambien tendras muchas
clases, pero 200 tablas no es tan poco, tu codigo tampoco sera menor usando
tu modalidad. Y encima tienes que escribir a mano todo el codigo con lo cual
como decia mas arriba terminas siendo muy poco productivo. No me imagino
todo el trabajo que tendria que hacer sin un generador para hacer un sistema
que tenga 200 u 800 tablas !!

For Each cliente As Cliente In misClientes
'Aqui hago lo que quiero con cada cliente..
cliente.Nombre
cliente.Edad
etc..
Next

No se para que podrías querer recorrer la lista. Si te traes todos los
datos ya masticados le enchufas la lista al grid o usas databindings y
listo. Para hacer databindings no hay ninguna necesidad de usar
datasets tipados ni colecciones de este tipo, te llega con una clase
genérica del estilo de DataTable, y te ahorras todo este follón y
engordar las aplicaciones con código que no aporta nada.

Solo mostraba lo facil que es recorrer la lista sin tener que recurrir a
dataRows y clases que no tienen que ver con el dominio de la aplicacion,
tambien puedo asignarlo a una grilla asi de facil:

DataGrid1.DataSoruce = misClientes;

Sigo sin verle utilidad a todo esto, pero por lo menos no lo usas para
hacer las típicas atrocidades del OR Mapping. La gestión de los datos
la sigue haciendo el SGBD. Hacer estas consultas mediante código VB o
C# sería una locura.

Pues a mi me resulta mucho mas natural escribir mis procesos usando objetos
y no registros.
El codigo de las reglas del negocio se simplifica muchisimo ya que no tenga
cantidad de metodos, y propiedades como los de un dataset o datatable en mis
objetos.

Los ORM utilizan objetos para armar la consulta y luego ejecutarla, pero al
fin siempre es el motor quien termina realizando el Select, no veo porque
deba ser una atrocidad.

Saludos, Eugenio Serrano
Microsoft MVP (ASP/ASP.Net)
Solid Quality Mentors

news:

On Wed, 7 Mar 2007 18:58:34 -0300, "Eugenio Serrano [MVP]" <eserrano
{-AT-} solidqualitylearning.com> wrote:

cmd.Parameters["@p_name"].Value = custName;
cmd.Parameters["@p_birthdate"].Value = dateOfBirth;
cmd.Parameters["@p_city"].Value = cityName;

cmd.ExecuteNonQuery();

Que es más o menos igual de engorroso que con Cooperator Framework.

Falta muuuchisimo mas codigo... eso es solo para una tabla...

No falta casi nada, pero esto es una forma muy mala de programar.

Donde pones la logica ?

Habría que hacerlo sin nada de código con databindings.

Seguro que sin nada de código? o hablas de codigo no generado?

La orden tiene una cabecera y un detalle... Necesitas escribir muuuucho
mas
codigo, mucho mas que mi ejemplo usando Cooperator.

Con Delphi haces eso y mucho más con cero líneas de código.

Como se hace ? Da un ejemplo, si puedes.

Crear
órdenes de esa forma es una chapuza.

Y entonces, cual es la forma correcta que propones?

Con datasets tipados también
puedes hacerlo con cero líneas de código.

De nuevo, seguro que no genera lineas de codigo? Te refieres al codigo no
generado?

http://www.intsight.com/whidbeydb/whidbey.html

De todas formas eso solo "resuelve" una pequeñísima parte de lo que es
una aplicación.

Como mercadeo el ejemplo de ese link esta bien pero nadie programa para
produccion un form de mantenimiento sin paginar, es decir sin llenar los
datatables con todos los registros de las tablas como hace ese video.
Ademas, genera mucho codigo por detras que es lo que has estado criticando.



A mi me ha surgido una duda, en que lenguaje tu programas actualmente ?
Programas actualmente?