Últimos mensajes - Powered by IBM

Palabras claves

DESARROLLO EN 3 CAPAS

24/11/2005 - 18:19 por Cristian Ledesma | Informe spam

Hola a todos soy nuevo en la dicusion, y la verdad las Respuestas del
compañero Alfredo Novoa realemente son buenas, me gustaria que si pudieras
me quitaras una duda, yo he trabajado en Win32 exactamente como tu
describes, todo el negocio en la Base de datos, por varios motivos unos de
ellos es que al cambiar una regla solo modifico en la BD y luego ya esta
todas las aplicaciones que acceden a la BD ya no es necerario tocar nada,
ahora mi problema es que realmente eso seria 2 capas, la del usuario y la de
la Base de datos(Bussines + SP's) lo cual no es complejo de mantener, pero
he visto en ejemplos del .net princiapalmente en VS2003 que todos o casi
todos implementan el uso de Clases de persistencia(objetos) en ves de
DataSet's que seria lo ideal pues el DataSet ya trae consigo los eventos
donde se puede validar mejor ademas de trabajar desconectado etc, en tu
opinion para una aplicacion Winforms cual seria la forma correcta de
implementar esto.

1. - Generar Clases para la Persistencia y esta persistencia es la que hace
el Binding correspondiente.
2.- Trabajar directamente el DataSet' para Persistir los datos y de alli
directamene a la BD.

Atte. Cristian Ledesma

Siga el debate

16 respuestas

Tengo una respuesta

Preguntas similare

desarrollo en 3 capas

Leer las respuestas

#11 Alfredo Novoa

12/12/2005 - 12:22 | Informe spam

On Sat, 10 Dec 2005 12:54:48 -0500, "fareyarlena"
wrote:

>Con "DataBindings".
Esa forma consumen recursos porque requiere estar conectado

Pero yo me estoy creando mis propias bibliotecas de clases para poder
prescindir de System.Data y trabajar siempre conectado entre otras
cosas.

Pero si lo que se busca es estar desconectado?

Entonces lo que se busca es un disparate.

Si quieres poder trabajar desconectado del SGBD central entonces
necesitas un SGBD local.

A no ser que la aplicación sea completamente trivial y te apañes
usando un simple archivo de texto.

Apoyo en cierta manera tu punto de vista, pero voy a hacer algunas
aclaraciones
no hay duda que crear varias clases que funcionen como el table adapter es
algo
en cierta forma derrochadora de tiempo, pero en vb6.0 es una forma rapida de
hacerlo,

Pero en vb6.0 tienes los recordsets, que se parecen bastante a los
TableAdapter.

Aunque yo de vb6 no se mucho por que vengo de Delphi. Hay cosas que
son muy sencillas con Delphi y que con VS.Net cuestan mucho trabajo.

otra idea podria hacer como en un ejemplo de .net , crear una clase
que manipule los datos, es decir las inserciones, los store procedures, hay

Manipular no. Comunicar el SGBD con la interfaz.

un codigo
que sale en universidad .net pero el problema es que usa ciertas
caracteristicas de .net
que no las encuentro en vb6.0 , por ejemplo perdona mi ignorancia, pero la
clase
del ejemplo recupera los argumentos del store procedure, y los adapta
deacuerdo al
store procedure que envies, en verdad estuvo complicado en hacer algo
similar al 6.0
no digo que no se puede pero consume tiempo

Y además es una mala forma de trabajar. Para comunicarnos con el SGBD
solo necesitamos insert, select, update y delete.

Insertar registros llamando a un procedimiento almacenado es una
tontería que no tiene ningún sentido.

Lo de las entidades de negocio, o clases que son iguales a las entidades del
modelo de datos

Iguales nunca son, por que una tabla no tiene nada que ver con una
clase.

son a mi parece utiles, porque puedes luego utilizarlas en otro proyecto ,
puede ser para una
pagina web, etc sin tener que hacer mucho cambio al codigo.

Me parece muy improbable que puedan volverse a utilizar, en cambio los
TableAdapters si que se pueden utilizar en cualquier proyecto de bases
de datos.

Saludos

Responder a este mensaje

#12 news.microsoft.com

04/01/2006 - 15:16 | Informe spam

Amigo hasta ahora concordaba en algunas cosas contigo, pero lo de los store
procedures, no me vas a negar que es mejor utilizarlos,
Que pasa si quieres anadir alguna funcionalidad extra, vuleves a recompilar
el programa?, ademas de que su uso agiliza las consultas,
ademas de que reduce la necesidad de otorgar permisos a los usuarios sobre
las tablas directamente, con el incremento de seguridad.
Creo que cuando mencione que eras administrador de bd mas que desarrollador
no me equivoque, jajajajja

Responder a este mensaje

#13 Alfredo Novoa

04/01/2006 - 16:35 | Informe spam

On Wed, 4 Jan 2006 09:16:04 -0500, "news.microsoft.com"
wrote:

Amigo hasta ahora concordaba en algunas cosas contigo, pero lo de los store
procedures, no me vas a negar que es mejor utilizarlos,

Pues si que te lo voy a negar :-)

Que pasa si quieres anadir alguna funcionalidad extra, vuleves a recompilar
el programa?

Pues no tendría por que.

, ademas de que su uso agiliza las consultas,

Esto no es cierto.

ademas de que reduce la necesidad de otorgar permisos a los usuarios sobre
las tablas directamente, con el incremento de seguridad.

Es que la gestión de la seguridad consiste entre otras cosas en
otorgar los permisos sobre las tablas adecuadamente.

Con lo que tu dices no se gana nada. No tienes que otorgar permisos
sobre las tablas pero tienes que hacerlo sobre los stored procedures.
No ganas nada.

Saludos
Alfredo

Responder a este mensaje

#14 consultS

20/01/2006 - 01:36 | Informe spam

Que pasa si quieres anadir alguna funcionalidad extra, vuleves a
recompilar
el programa?

Pues no tendría por que.

SI LA CONSULTA QUE USAS ESTA DENTRO DEL PROGRAMA Y QUIERES CAMBIARLA
COMO HACES SIN VOLVER A COMPILAR EL PROGRAMA, ENSEÑAME ESA MAGIA

Responder a este mensaje

#15 Alfredo Novoa

20/01/2006 - 09:33 | Informe spam

On Thu, 19 Jan 2006 19:36:07 -0500, "consultS"
wrote:

Que pasa si quieres anadir alguna funcionalidad extra, vuleves a
recompilar
el programa?

Pues no tendría por que.

SI LA CONSULTA QUE USAS ESTA DENTRO DEL PROGRAMA Y QUIERES CAMBIARLA
COMO HACES SIN VOLVER A COMPILAR EL PROGRAMA, ENSEÑAME ESA MAGIA

Es que se trata precisamente de evitar eso que dices, y la mejor forma
de hacerlo no es casi nunca usar procedimientos almacenados.

Se puede añadir funcionalidad extra a la base de datos sin tener que
cambiar las consultas que están en los programas. Ahí está la "magia"
de la independencia lógica que proporciona el Modelo Relacional.

La forma más normal de hacer esto es usar vistas y sinónimos en lugar
de procedimientos almacenados.

Pero tampoco es imprescindible crear vistas para todas las tablas en
previsión de que puedas hacer cambios, por que siempre puedes
renombrar una tabla y crear una vista con el nombre y estructura
anteriores de la tabla. También puedes jugar con los permisos y
presentar distintas estructuras de base de datos dependiendo de cuál
sea la aplicación que se conecta.

Saludos

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4

Busqueda sugerida