Las famosas n capas.

On Wed, 13 Apr 2005 15:12:12 -0400, "Patrick Mac Kay"
<pmackay_at_hotmail.com> wrote:

la utilización de 2 o 3 capas puede quedar a tu criterio. Si tu
aplicación es pequeña y no debiera variar en el tiempo, no es pecado hacerla
de 2 capas. Pero en el caso de que sea un aplicación grande, y donde la
mantenibilidad sea importante, te recomiendo hacerla en 3 capas. Una capa
para la presentación (winform, aspnet), la siguiente para tus reglas de
negocio y por ultimo la capa de datos, que no tiene nada que ver con todos
los terminos que se han nombrado en esta discusión. Esto debes acompañarlo
de tus entidades de negocio. Si la aplicación es chica, podrías no necesitar
entidades de negocio, pero te las recomiendo igual.

Para aclarar de una vez, la capa de datos es la encargada de conectarse con
el motor de datos y pedirle que ejecute ciertos comandos.

Estamos hablando de cosas distintas. Tu estás hablando de las capas de
una aplicación cliente y yo he hablado de las capas de un sistema.

Un sistema está compuesto por distintos componentes, y las
aplicaciones cliente son solo una de ellos: la capa de presentación.
Es decir que tu estás hablando de las capas de la capa de
presentación.

Por otra parte las reglas de negocio nunca se deben de implementar en
la aplicación cliente (capa de presentación), y como subcapa de acceso
al SGBD se puede usar ADO.NET por ejemplo.

Cada uno llama capas a lo que le da la gana. Hay capas lógicas y capas
físicas, y cada capa puede tener subcapas.

Yo he estado hablando todo el rato de las capas lógicas de un sistema,
pero hay mucha gente que habla de las capas físicas.

De acuerdo con el criterio de las capas físicas los sistemas de
información se clasificarían así:

1 capa:

Un sistema en el que las aplicaciones acceden directamente a la base
de datos. Ejemplo: un conjunto de aplicaciones que leen los datos de
un mismo fichero .MDB

2 capas:

Un sistema que utiliza un SGBD y un conjunto de aplicaciones cliente.
Ejemplo: la típica aplicación cliente servidor que usa SQL Server.

3 capas:

Un sistema en el que el SGBD está formado por 2 capas físicas. Ejemplo
un sistema con un conjunto de aplicaciones cliente que se conectan a
DataJoiner de IBM y DataJoiner a se conecta a su vez a DB2.

Los comandos
pueden ser en sql dinamico (string concatenado) como tambíen procedimientos
almacenados. Te recomiendo 100% los procedimientos almacenados, ya sea por
motivos de permisos, rendimiento y seguridad.

Motivos infundados como ya hemos visto.

La capa de datos NO es ADO.NET ni tampoco MS Data Access Application block
(MSDAAB). La capa de datos recibe requerimientos desde negocio y los
ejecuta. Con esto, abstraes del tejemaneje y la plomería de tu motor de
datos a la capa de negocios.

Utilizas una terminología muy mala y poco profesional. Supongo que a
lo que tu llamas "motor de datos" es al SGBD, pero el SGBD ya es una
capa de abstracción de la base de datos y no hay que abstraer una capa
de abstracción relacional con un primitivo interfaz procedimental
hecho en casa.

Lo que pretendes es montar un arcaico procesador de archivos encima
del SGBD. A eso es a lo que llamas capa de datos.

Si el "motor de datos" fuese MS Jet u otro procesador de archivos,
estaríamos hablando de una aplicación de 1 capa física y 2 capas
lógicas. Algo nada recomendable.

Nunca deberíamos usar un "motor de datos" que no fuese un SGBD excepto
para aplicaciones triviales.


Saludos

On Wed, 13 Apr 2005 19:49:06 +0200, "manolo"
wrote:

Yo pretendo crear una librería que gestione los datos de forma genérica
para mi aplicación y luego uno o más frontends que gestionen la librería, es
decir, un proyecto winforms que haga:

dim A as Datos.Articulos
CargarListView A.Todos

Y del mismo modo, crear una página web en asp que haga:

dim A as Datos.Articulos
CargarGrid A.todos

Todos es un método que devuelve un DataReader con todos los artículos
que no están borrados.

Espero haberme explicado. Esta forma de programar no la tengo aún muy
controlada.

Las aplicaciones no deben gestionar los datos, los datos deben de ser
gestionados por el Sistema de Gestión de Base de Datos, por eso se
llama así.

Lo que debe de gestionar la aplicación es la presentación de los datos
y la comunicación con los usuarios.

En este caso estamos hablando de las capas de la aplicación y no de
las capas del sistema.

Es decir que estamos hablando de las subcapas de la capa de
presentación. Aquí no hay ninguna capa de negocio ni de datos.

Aclarado esto yo no veo ninguna ventaja a tu código con respecto a
utilizar directamente las clases de ADO.NET. Si estás en un proyecto
WinForms enlazas la propiedad datasource de un grid a un DataTable, si
estás en una aplicación Web, pues exactamente lo mismo.


Saludos

Uff...sin comentarios.

Manolo... todo lo que te comenté esta en cualquier libro de arquitectura de
aplicaciones, partiendo por el link de mas abajo. Sientete libre de buscar
en el que estimes necesario y si tienes dudas de implementación
conversémoslas.

http://msdn.microsoft.com/architect...istapp.asp

No te gastes mas discutiendo en este hilo por que como ves, hay un grupo de
personas de acuerdo y uno solo que ve otra realidad.

Saludos.

Patrick.


"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 13 Apr 2005 15:12:12 -0400, "Patrick Mac Kay"
<pmackay_at_hotmail.com> wrote:

> la utilización de 2 o 3 capas puede quedar a tu criterio. Si tu
>aplicación es pequeña y no debiera variar en el tiempo, no es pecado

hacerla

>de 2 capas. Pero en el caso de que sea un aplicación grande, y donde la
>mantenibilidad sea importante, te recomiendo hacerla en 3 capas. Una capa
>para la presentación (winform, aspnet), la siguiente para tus reglas de
>negocio y por ultimo la capa de datos, que no tiene nada que ver con

todos

>los terminos que se han nombrado en esta discusión. Esto debes

acompañarlo

>de tus entidades de negocio. Si la aplicación es chica, podrías no

necesitar

>entidades de negocio, pero te las recomiendo igual.
>
>Para aclarar de una vez, la capa de datos es la encargada de conectarse

con

>el motor de datos y pedirle que ejecute ciertos comandos.

Estamos hablando de cosas distintas. Tu estás hablando de las capas de
una aplicación cliente y yo he hablado de las capas de un sistema.

Un sistema está compuesto por distintos componentes, y las
aplicaciones cliente son solo una de ellos: la capa de presentación.
Es decir que tu estás hablando de las capas de la capa de
presentación.

Por otra parte las reglas de negocio nunca se deben de implementar en
la aplicación cliente (capa de presentación), y como subcapa de acceso
al SGBD se puede usar ADO.NET por ejemplo.

Cada uno llama capas a lo que le da la gana. Hay capas lógicas y capas
físicas, y cada capa puede tener subcapas.

Yo he estado hablando todo el rato de las capas lógicas de un sistema,
pero hay mucha gente que habla de las capas físicas.

De acuerdo con el criterio de las capas físicas los sistemas de
información se clasificarían así:

1 capa:

Un sistema en el que las aplicaciones acceden directamente a la base
de datos. Ejemplo: un conjunto de aplicaciones que leen los datos de
un mismo fichero .MDB

2 capas:

Un sistema que utiliza un SGBD y un conjunto de aplicaciones cliente.
Ejemplo: la típica aplicación cliente servidor que usa SQL Server.

3 capas:

Un sistema en el que el SGBD está formado por 2 capas físicas. Ejemplo
un sistema con un conjunto de aplicaciones cliente que se conectan a
DataJoiner de IBM y DataJoiner a se conecta a su vez a DB2.

> Los comandos
>pueden ser en sql dinamico (string concatenado) como tambíen

procedimientos

>almacenados. Te recomiendo 100% los procedimientos almacenados, ya sea

por

>motivos de permisos, rendimiento y seguridad.

Motivos infundados como ya hemos visto.

>La capa de datos NO es ADO.NET ni tampoco MS Data Access Application

block

>(MSDAAB). La capa de datos recibe requerimientos desde negocio y los
>ejecuta. Con esto, abstraes del tejemaneje y la plomería de tu motor de
>datos a la capa de negocios.

Utilizas una terminología muy mala y poco profesional. Supongo que a
lo que tu llamas "motor de datos" es al SGBD, pero el SGBD ya es una
capa de abstracción de la base de datos y no hay que abstraer una capa
de abstracción relacional con un primitivo interfaz procedimental
hecho en casa.

Lo que pretendes es montar un arcaico procesador de archivos encima
del SGBD. A eso es a lo que llamas capa de datos.

Si el "motor de datos" fuese MS Jet u otro procesador de archivos,
estaríamos hablando de una aplicación de 1 capa física y 2 capas
lógicas. Algo nada recomendable.

Nunca deberíamos usar un "motor de datos" que no fuese un SGBD excepto
para aplicaciones triviales.


Saludos

On Wed, 13 Apr 2005 18:04:42 -0400, "Patrick Mac Kay"
<pmackay_at_hotmail.com> wrote:

Uff...sin comentarios.

Manolo... todo lo que te comenté esta en cualquier libro de arquitectura de
aplicaciones, partiendo por el link de mas abajo. Sientete libre de buscar
en el que estimes necesario y si tienes dudas de implementación
conversémoslas.

http://msdn.microsoft.com/architect...istapp.asp

Eso es un panfleto de muy mala calidad escrito por programadores sin
formación en teoría de bases de datos.

Deberíais leer algún libro serio sobre el tema firmado por alguna
autoridad en la materia.


Saludos

¿Como resolverias entonces lo que pretende hacer Manolo? Porque acceder
directamente a la BD, SGBD, motor de BD o como quieras llamarlo implica
duplicar las consultas en las dos aplicaciones, lo cual complica el
mantenimiento.

WinForms enlazas la propiedad datasource de un grid a un DataTable, si
estás en una aplicación Web, pues exactamente lo mismo.

¿Y esto que tendra que ver?

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
https://mvp.support.microsoft.com/p...4EF5A4191C
http://spaces.msn.com/members/emorcillo/