Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

¿Programo bien?

30/01/2007 - 21:08 por alberto | Informe spam
Ayuda Hacer una pregunta
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.
email Siga el debateRespuesta 90 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#6 Alfredo Novoa
31/01/2007 - 12:10 | Informe spam
On Tue, 30 Jan 2007 23:17:12 -0400, "Carlos" wrote:

Cuando le dices al companero que no es el modo correcto de afrontar el
desarrollo de una aplicacion, te refieres a la definicion y manejo de sus
"clases de negocio" como lo siguiente?

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







Si. Este ejemplo es trivial. El problema es cuando intentas hacer
cosas algo más complicadas de esta forma.

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

Asumiendo el mismo ejemplo que da el amigo, cual sería para ti una manera
más adecuada de tratarlo ? Puedes rehacer el ejemplo con la idea que
planteas?



1) Utilizo un SGBD para gestionar los datos de forma que este
garantice su integridad y calcule los nuevos datos que se necesiten.

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.


Saludos
Alfredo
Respuesta Responder a este mensaje
#7 Alfredo Novoa
31/01/2007 - 12:36 | Informe spam
Hola Carlos,

On Tue, 30 Jan 2007 23:17:12 -0400, in microsoft.public.es.csharp you
wrote:

Me olvidé de contestar a esto:

Enseña ese libro a hacer una aplicación del lado del cliente (front-end) ?



No, pero te enseña muchas cosas que tienes que saber antes de aprender
a hacer una aplicación del lado del cliente.


Saludos
Alfredo
Respuesta Responder a este mensaje
#8 Carlos
31/01/2007 - 13:17 | Informe spam

Si. Este ejemplo es trivial. El problema es cuando intentas hacer
cosas algo más complicadas de esta forma.



Estoy de acuerdo


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

Asumiendo el mismo ejemplo que da el amigo, cual sería para ti una manera
más adecuada de tratarlo ? Puedes rehacer el ejemplo con la idea que
planteas?



1) Utilizo un SGBD para gestionar los datos de forma que este
garantice su integridad y calcule los nuevos datos que se necesiten.




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.


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? es decir mapeando la entidad
cliente como una clase (objeto) en la aplicación. Tienes otra alternativa
para eso mismo, o ejemplo?

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

Gracias por tu ayuda.
Respuesta Responder a este mensaje
#9 Alfredo Novoa
31/01/2007 - 13:24 | Informe spam
On 31 Jan 2007 00:30:09 -0800, "ANT1" wrote:

Hola,

He estado echando un ojo al libro (los indices que vienen por
internet), tiene buena pinta.

¿Pero me podrias decir si tambien explican todo lo relacionado con
sesiones, factorias, long session y demas?



No, nada de eso. Explica cosas mucho más fundamentales e
independientes de una implementación concreta.

Te explica que es realmente y para que sirve un Sistema de Bases de
datos, y lo mismo para Modelo Relacional. Algo que pocos programadores
de aplicaciones comprenden bien, y también pocos escritores de libros
de SQL Server.

Yo tampoco lo entendía bien antes de leer ese libro. Las bases de
datos se enseñan fatal en casi todas partes, universidades incluidas.

Con una buena base como esa se evitan muchos errores como el de
gestionar los datos usando "objetos de negocio".

El autor fue uno de los primeros en conocer el Modelo Relacional y el
principal colaborador del inventor del Modelo Relacional. Actualmente
es el principal "mantenedor" del Modelo Relacional. Se nota que sabe
de lo que escribe. No encontrarás información de más "primera mano".


Saludos
Alfredo
Respuesta Responder a este mensaje
#10 Alberto
31/01/2007 - 13:33 | Informe spam
A mi también me gustaría profundizar más. Creo que podríamos establecer aquí
un pequeño debate.
Gracias a todos.

"Carlos" escribió en el mensaje
news:


Si. Este ejemplo es trivial. El problema es cuando intentas hacer
cosas algo más complicadas de esta forma.



Estoy de acuerdo


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

Asumiendo el mismo ejemplo que da el amigo, cual sería para ti una manera
más adecuada de tratarlo ? Puedes rehacer el ejemplo con la idea que
planteas?



1) Utilizo un SGBD para gestionar los datos de forma que este
garantice su integridad y calcule los nuevos datos que se necesiten.




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.


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? es decir mapeando la
entidad cliente como una clase (objeto) en la aplicación. Tienes otra
alternativa para eso mismo, o ejemplo?

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

Gracias por tu ayuda.





Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida