Las famosas n capas.

La respuesta corta es: depende.

Pongamos el caso de validación de campos (que el usuario
mete una fecha válida en un campo de fecha, por ejemplo).
Podrías validar los campos en la base de datos con un
trigger y aceptar cualquier cosa en las capas servidor y
cliente. Esto haría que tanto el servidor como el cliente
fueran muuuuy rápido, pero cargarías muchísimo el servidor
de BD. Entonces qué haces: mover la validación de campos a
la capa servidor, así descargas la BD, pero cargas el
servidor. Al final te das cuenta que lo mejor es validar
en el cliente. Así ni el servidor ni la BD se sobrecargan
haciendo cosas que se pueden hacer facilmente en el
cliente. Además ahorras tráfico de red, con lo que la
aplicación irá mejor.

Mi recomendación es que metas en el cliente todo lo que no
necesite conexión con el servidor. Incluso si tienes
tablas pequeñas en la BD que vas a consultar
frecuentemente, cárgalas en memoria en el cliente, siempre
teniendo en cuenta el rendimiento que te da. El resto, si
necesita acceso a datos, mételo en la BD y si no, en el
servidor. Minimiza el tráfico de red todo lo que puedas.

Hola,

¿Alguien tiene algún enlace en el cual se expliquen

las aplicaciones en

n capas?
Yo estoy interesado en las de 3 capas, ya que estoy

muy liado, me

confundo sobre todo entre que poner en la capa de datos y

en la capa de

negocio. La capa superior está más bien clara, ya que es

la más fácil de

implementar.

Muchas gracias y un saludo.


.

Hola,

Muchas gracias.
Entonces, ¿quieres decir que me olvide de la capa de datos y cree solo
una biblioteca de clases que accedan a la base de datos y un programa con la
validación y el interfaz?
Cuando digo olvidarme de la capa de datos quiero decir de la validación,
no de los sp's, vistas y triggers estrictamente necesarios.

Un saludo.

escribió en el mensaje
news:1f7301c53e95$0ed386c0$
La respuesta corta es: depende.

Pongamos el caso de validación de campos (que el usuario
mete una fecha válida en un campo de fecha, por ejemplo).
Podrías validar los campos en la base de datos con un
trigger y aceptar cualquier cosa en las capas servidor y
cliente. Esto haría que tanto el servidor como el cliente
fueran muuuuy rápido, pero cargarías muchísimo el servidor
de BD. Entonces qué haces: mover la validación de campos a
la capa servidor, así descargas la BD, pero cargas el
servidor. Al final te das cuenta que lo mejor es validar
en el cliente. Así ni el servidor ni la BD se sobrecargan
haciendo cosas que se pueden hacer facilmente en el
cliente. Además ahorras tráfico de red, con lo que la
aplicación irá mejor.

Mi recomendación es que metas en el cliente todo lo que no
necesite conexión con el servidor. Incluso si tienes
tablas pequeñas en la BD que vas a consultar
frecuentemente, cárgalas en memoria en el cliente, siempre
teniendo en cuenta el rendimiento que te da. El resto, si
necesita acceso a datos, mételo en la BD y si no, en el
servidor. Minimiza el tráfico de red todo lo que puedas.

Hola,

¿Alguien tiene algún enlace en el cual se expliquen

las aplicaciones en

n capas?
Yo estoy interesado en las de 3 capas, ya que estoy

muy liado, me

confundo sobre todo entre que poner en la capa de datos y

en la capa de

negocio. La capa superior está más bien clara, ya que es

la más fácil de

implementar.

Muchas gracias y un saludo.


.

On Mon, 11 Apr 2005 05:50:36 -0700,
wrote:

Pongamos el caso de validación de campos (que el usuario
mete una fecha válida en un campo de fecha, por ejemplo).
Podrías validar los campos en la base de datos con un
trigger

Lo que podrías hacer es crear una restricción de integridad utilizando
un SGBD. Un trigger sería la peor forma de hacerlo. Sería mucho mejor
utilizar un dominio.

y aceptar cualquier cosa en las capas servidor y
cliente.

Un SGBD es un servidor.

Esto haría que tanto el servidor como el cliente
fueran muuuuy rápido, pero cargarías muchísimo el servidor
de BD.

En el caso que describes lo que tendrías es un SGBD distribuido.

Una posible configuración podría ser esta:

Aplicaciones
|
SGBD Middleware
/ | \
SGBD Final SGBD Final SGBD Final

Pero también podríamos crear muchas otras según nuestras necesidades.
Podríamos tener más o menos servidores finales, más servidores medios
o prescindir de los servidores medios y tener un solo servidor final
(a eso se le llama 2 capas). Las posibilidades son muchas.

Lo que es fundamental es que el SGBD que es visto por las aplicaciones
(en este caso el medio) sea relacional.

Por otra parte es completamente ridículo decir que validar una fecha
cargaría muchísimo un servidor moderno, y menos si podemos usar
varios.

Al final te das cuenta que lo mejor es validar
en el cliente. Así ni el servidor ni la BD se sobrecargan
haciendo cosas que se pueden hacer facilmente en el
cliente.

Esto es un grandísimo disparate y va totalmente en contra de todo lo
que se enseña en cualquier curso básico sobre bases de datos.

Las reglas de integridad deben de estar centralizadas y no
desperdigadas por las aplicaciones cliente. Uno de los objetivos
fundamentales de los SGBD es garantizar la integridad de los datos, y
las razones para esto vienen explicadas en el primer capítulo de
cualquier introducción seria a los sistemas de bases de datos.

Mi recomendación es que metas en el cliente todo lo que no
necesite conexión con el servidor.

Mi recomendación es que estudies algo sobre bases de datos.

Incluso si tienes
tablas pequeñas en la BD que vas a consultar
frecuentemente, cárgalas en memoria en el cliente, siempre
teniendo en cuenta el rendimiento que te da.

La manera correcta de hacer eso es utilizar un SGBD distribuido con
una parte que se ejecutase en el ordenador cliente de foma que las
tablas y las restricciones de integridad seguirían controladas por el
SGBD.

Es decir, tener un servidor "MiddleWare" ejecutandose en el mismo
ordenador que la aplicación cliente.

El resto, si
necesita acceso a datos, mételo en la BD y si no, en el
servidor. Minimiza el tráfico de red todo lo que puedas.

Minimizar el tráfico de red es importante y se puede conseguir con un
SGBD distribuido, pero hay cosas mucho más importantes como garantizar
la integridad de los datos y minimizar el tiempo de desarrollo.

Implementar las restricciones de integridad y gestionar los datos
desde la capa de aplicación es una práctica desastrosa que quedó
obsoleta hace varias décadas. El problema es que los que no conocen
los errores del pasado están condenados a repetirlos.


Saludos

Hola,

En principio, la base de datos la tengo de la siguiente manera:
- Tablas relacionadas.
- Procedimientos almacenados que almacenan, modifican y eliminan los
registros de las tablas.
- Vistas que devuelven los datos de varias tablas.
- Restricciones que Gestionan los datos como fechas, descripciones, etc.
- Triggers que actualizan datos no relacionados.
- Funciones de cálculo para facturas, albaranes, etc...

Mi problema, es que he leido en varios sitios que se puede crear por
encima de la db una capa de datos que acceda a la base de datos, es decir,
una clase que tenga los objetos de lectura y escritura a la base de datos y
una capa por encima que utilizando esta mantenga los datos en clases, la
capa empresarial.
En principio, el proyecto es pequeño, pero debe poder ser escalable, por
que no se sabe si en un futuro necesitará ampliaciones importantes que
requieran varios servidores, etc.

Muchas gracias y un saludo.


"Alfredo Novoa" escribió en el mensaje
news:

On Mon, 11 Apr 2005 05:50:36 -0700,
wrote:

Pongamos el caso de validación de campos (que el usuario
mete una fecha válida en un campo de fecha, por ejemplo).
Podrías validar los campos en la base de datos con un
trigger

Lo que podrías hacer es crear una restricción de integridad utilizando
un SGBD. Un trigger sería la peor forma de hacerlo. Sería mucho mejor
utilizar un dominio.

y aceptar cualquier cosa en las capas servidor y
cliente.

Un SGBD es un servidor.

Esto haría que tanto el servidor como el cliente
fueran muuuuy rápido, pero cargarías muchísimo el servidor
de BD.

En el caso que describes lo que tendrías es un SGBD distribuido.

Una posible configuración podría ser esta:

Aplicaciones
|
SGBD Middleware
/ | \
SGBD Final SGBD Final SGBD Final

Pero también podríamos crear muchas otras según nuestras necesidades.
Podríamos tener más o menos servidores finales, más servidores medios
o prescindir de los servidores medios y tener un solo servidor final
(a eso se le llama 2 capas). Las posibilidades son muchas.

Lo que es fundamental es que el SGBD que es visto por las aplicaciones
(en este caso el medio) sea relacional.

Por otra parte es completamente ridículo decir que validar una fecha
cargaría muchísimo un servidor moderno, y menos si podemos usar
varios.

Al final te das cuenta que lo mejor es validar
en el cliente. Así ni el servidor ni la BD se sobrecargan
haciendo cosas que se pueden hacer facilmente en el
cliente.

Esto es un grandísimo disparate y va totalmente en contra de todo lo
que se enseña en cualquier curso básico sobre bases de datos.

Las reglas de integridad deben de estar centralizadas y no
desperdigadas por las aplicaciones cliente. Uno de los objetivos
fundamentales de los SGBD es garantizar la integridad de los datos, y
las razones para esto vienen explicadas en el primer capítulo de
cualquier introducción seria a los sistemas de bases de datos.

Mi recomendación es que metas en el cliente todo lo que no
necesite conexión con el servidor.

Mi recomendación es que estudies algo sobre bases de datos.

Incluso si tienes
tablas pequeñas en la BD que vas a consultar
frecuentemente, cárgalas en memoria en el cliente, siempre
teniendo en cuenta el rendimiento que te da.

La manera correcta de hacer eso es utilizar un SGBD distribuido con
una parte que se ejecutase en el ordenador cliente de foma que las
tablas y las restricciones de integridad seguirían controladas por el
SGBD.

Es decir, tener un servidor "MiddleWare" ejecutandose en el mismo
ordenador que la aplicación cliente.

El resto, si
necesita acceso a datos, mételo en la BD y si no, en el
servidor. Minimiza el tráfico de red todo lo que puedas.

Minimizar el tráfico de red es importante y se puede conseguir con un
SGBD distribuido, pero hay cosas mucho más importantes como garantizar
la integridad de los datos y minimizar el tiempo de desarrollo.

Implementar las restricciones de integridad y gestionar los datos
desde la capa de aplicación es una práctica desastrosa que quedó
obsoleta hace varias décadas. El problema es que los que no conocen
los errores del pasado están condenados a repetirlos.


Saludos

Hola

On Tue, 12 Apr 2005 10:53:39 +0200, "manolo"
wrote:

En principio, la base de datos la tengo de la siguiente manera:
- Tablas relacionadas.
- Procedimientos almacenados que almacenan, modifican y eliminan los
registros de las tablas.

Este tipo de procedimientos suelen ser un error. Casi siempre es mejor
gestionar las tablas usando SQL, y además requiere mucho menos
trabajo.

- Vistas que devuelven los datos de varias tablas.
- Restricciones que Gestionan los datos como fechas, descripciones, etc.
- Triggers que actualizan datos no relacionados.
- Funciones de cálculo para facturas, albaranes, etc...

Todo esto me parece bien, aunque se deben favorecer las vistas sobre
los triggers y las funciones de cálculo siempre que sea posible por
que son mucho más rápidas de desarrollar, fáciles de mantener y son
menos propensas a errores.

Mi problema, es que he leido en varios sitios que se puede crear por
encima de la db una capa de datos que acceda a la base de datos

Vamos a ver, el que accede a la base de datos es el SGBD, por ejemplo
SQL Server.

, es decir,
una clase que tenga los objetos de lectura y escritura a la base de datos y
una capa por encima que utilizando esta mantenga los datos en clases, la
capa empresarial.

Esto es una barbaridad, yo también he leido muchas tonterías acerca de
esto.

Lo que pretenden es montar un procesador de archivos encima del SGBD
por que no saben ni entienden lo que es un SGBD y están acostumbrados
a trabajar directamente con archivos.

Hay que tener mucho cuidado con lo que se lee, por que la mayoría de
la gente que anda escribiendo cosas por ahí no tiene ni idea.

En principio, el proyecto es pequeño, pero debe poder ser escalable, por
que no se sabe si en un futuro necesitará ampliaciones importantes que
requieran varios servidores, etc.

En este caso lo mejor sería crear un sistema de dos capas con la
lógica de negocio asegurada por el SGBD tal como tienes hecho. En caso
de necesitar más potencia el sistema sería fácilmente escalable
utilizando un SGBD distribuido.

Por ejemplo podrías empezar con la version estandar de tu SGBD y más
adelante pasarte a la versión superior utilizando varios servidores
federados.

http://msdn.microsoft.com/library/d...s_4fw3.asp

Los cambios que tendrías que hacer a las aplicaciones serían mínimos o
nulos.


Saludos