¿Programo bien?

Gracias por la respuesta. Miraré lo de TDD y el patrón MVC.

"Roberto M. Oliva" escribió en el mensaje
news:
Hola!

A mi me parece que es la manera correcta de hacer las cosas (tambien
dependera un poco de cual es el proyecto final, pero en general es
asi).
Yo solo te recomendaria incluir TDD (Test Driven Development). Es una
metodologia de testeos de clases. Con ella testeas toda la capa de
negocios. Por otro lado implanta un patron MVC en el lado del cliente
para que te ayude tambien a testear el interfaz de usuario.

Bueno, estos son mis consejos generales... sobre todo esto se puede
profudizar y mucho.
Saludos
Roberto M. Oliva


On 30 ene, 21:08, "alberto" wrote:

Menuda pregunta, no??

Os quiero contar brevemente cómo planteo el desarrollo de los proyectos
sencillos:

1) Trabajo con SQL Server y todas las instrucciones sql las almaceno como
procedimientos almacenados.
2) Tengo una biblioteca que contiene una clase que me da acceso a la base
de
datos. En esta clase tengo métodos que me dejan ejecutar instrucciones
tipo
Insert, Delete, etc. (vamos, las ExecuteNonQuery del objeto command),
métodos para obtener un escalar, etc.
Si, por ejemplo, quiero obtener un DataReader con ciertos datos, solo
tengo que hacer lo siguiente: SqlDataReader dr > bd.ObtenerDatos(nombreProcedimientoAlmacenado);
3) Tengo otra capa con los objetos de mi negocio (Clientes, facturas,
productos, etc) que es la que realmente se comunica con la capa de acceso
a
datos.
4) Finalmente, el interface solo se ocupa de trabajar con objetos de la
capa
de negocio. Si, por ejemplo, quiero grabar un cliente, haré algo parecido
a
lo siguiente:
miCliente.Dni = txtDni.Text;
miCliente.Nombre = txtNombre.Text;
miCliente.Grabar();

¿Considerais que es un modo correcto de afrontar el desarrollo de una
aplicación?
Muchísimas gracias por vuestra opinión.

On Wed, 31 Jan 2007 08:17:47 -0400, "Carlos"
wrote:

Y meter sistematicamente las consultas dentro de procedimientos
almacenados es otro absurdo.

Significa que conviene usar los SP's principalmente para acciones de
actualización ?

No, lo que conviene es no usar los SP. La mayoría de los SP que se
necesitan son triggers y también conviene usarlos lo menos posible.

Ahora mismo estamos pasando una aplicación vieja de DBase a SQL Server
y gracias a las vistas indexadas apenas estamos necesitando triggers
ni SP.

Estamos eliminando un montón de código de la aplicación que no se
convierte en código de servidor. Simplemente ya no es necesario
gracias al mayor nivel de abstracción de la programación declarativa.

y que las consultas deberían enviarse directamente desde
la aplicación? No "amarraría" esto más a la aplicación con el SGBD?

No. ¿Que diferencia hay entre "amarrarse" a tablas que a SP?

Lo que si hay que hacer es aprovechar el sistema de permisos, las
vistas, los alias, etc.

Considerando la ventaja de pre-compilación que aportan los SP's, no
convendría también tener las consultas más complejas/frecuentes en SP's?

Hay más formas de precompilar como por ejemplo vistas y preparación de
consultas. Además el tiempo de compilación no suele ser muy
significativo. Si reduces el tiempo de una consulta en 50 milisegundos
nadie te lo va a agradecer.

ok. Eso lo tengo claro. Las reglas de integridad de los datos y de sus
datos derivados deben ser responsabilidad unica y exclusiva del SGBD ya que
eso independiza los datos y su integridad, de la aplicación.

Exacto, y además le estamos danto oportunidades al optimizador para
hacer su trabajo.

2) La interfaz se ocupa de presentar los objetos de la base de datos a
los usuarios, comunicandose con el SGBD a través del lenguaje SQL.

Ok pero siguiendo el mismo ejemplo, aunque entendemos que es muy trivial, de
que otra manera se pueden "presentar los objetos" en la interfaz si no es de
forma parecida a la que propone el compañero?

Con datasets, y datatables.

es decir mapeando la entidad
cliente como una clase (objeto) en la aplicación.

No se puede mapear una tabla con una clase por que es absurdo, lo que
se hace es mapear una tabla con un objeto de tipo colección.

Tienes otra alternativa
para eso mismo, o ejemplo?

Un datatable directamente conectado por DataBindings a los controles
visuales.

No tiene ningún sentido hacer algo como esto:

miCliente.Dni = txtDni.Text;
miCliente.Nombre = txtNombre.Text;
miCliente.Grabar();

Cuando se usan "databindings"

nota:Disculpa la insistencia, es que me interesa profundizar en este tema
con fines de aclarar conceptos que tengo un poco confusos.

No hay nada que disculpar. Pregunta lo que quieras que yo responderé
lo que me de la gana :-)


Saludos
Alfredo

On Wed, 31 Jan 2007 11:05:25 +0100, "alberto"
wrote:

Antes de que decida si me interesa o no el libro, ¿me podrías justificar un
poquito tu respuesta?
Gracias

Mira lo que lo pongo a Carlos y mensajes anteriores sobre lo mismo. Te
sobran por lo menos dos "capas".

Saludos

Hola,

On 31 Jan 2007 02:21:14 -0800, "Roberto M. Oliva"
wrote:

Yo solo te recomendaria incluir TDD (Test Driven Development). Es una
metodologia de testeos de clases. Con ella testeas toda la capa de
negocios.

Si el objetivo es maximizar el coste de desarrollo entonces está muy
bien. Por supuesto también habría que crear clases para testear las
clases de testeo, y así sucesivamente.

Por otro lado implanta un patron MVC en el lado del cliente
para que te ayude tambien a testear el interfaz de usuario.

Pero hombre, como vas a implantar el patrón MVC en el cliente. Ese es
un patrón que tiene sentido a nivel de sistema. Es evidente que la
interfaz (cliente) corresponde con la vista.


Saludos

On 31 ene, 15:50, Alfredo Novoa wrote:

Hola,

On 31 Jan 2007 02:21:14 -0800, "Roberto M. Oliva"
wrote:

>Yo solo te recomendaria incluir TDD (Test Driven Development). Es una
>metodologia de testeos de clases. Con ella testeas toda la capa de
>negocios.

Si el objetivo es maximizar el coste de desarrollo entonces está muy
bien. Por supuesto también habría que crear clases para testear las
clases de testeo, y así sucesivamente.

Se ve que no sabes de que estoy hablando

>Por otro lado implanta un patron MVC en el lado del cliente
>para que te ayude tambien a testear el interfaz de usuario.

Pero hombre, como vas a implantar el patrón MVC en el cliente. Ese es
un patrón que tiene sentido a nivel de sistema. Es evidente que la
interfaz (cliente) corresponde con la vista.

Saludos

Tienes razon, me he expresado mal: No es implantar un patron MVC en el
cliente.
Es, simplemente implantar un patron MVC en la aplicacion para
facilitar los testeos del interfaz de usuario.

Un saludo
Roberto M. Oliva