Las famosas n capas.

Perdón, que me he equivocado:

bien sea windows o sea web, que utilice la librería para acceder a la base
de datos.

Quería decir que utilice la librería para gestionar los datos, no para
que la capa de presentación acceda a la base de datos, que es distinto.

Un saludo.

On Wed, 13 Apr 2005 13:38:29 +0200, "manolo"
wrote:

Según me recomendais, es que haga la capa de presentación y la capa
empresarial,

El problema es que cada uno le llama capa empresarial a una cosa
distinta. Yo creo que sería bueno utilizar términos más científicos,
que los hay.

pero discutís a cerca de consultar los datos por sp que por
sentencias

Eso al final es lo de menos. Las dos formas funcionan.

, pero el final son 3 capas: sql server, librería abstracta con
funciones de acceso al sistema gestor de bases de datos y una última capa,
bien sea windows o sea web, que utilice la librería para acceder a la base
de datos.

Las tres capas son:

Aplicaciones <> Sistema de Gestión de Bases de Datos <> Base de
Datos

Esto no varía nunca (excepto en sistemas arcaicos que tienen 2 capas,
los sistemas de 1 capa no existen), pero las dos primeras capas se
pueden descomponer en "subcapas".

Por ejemplo ADO.NET sería una subcapa dentro de la capa de
aplicaciones.



Saludos

On Wed, 13 Apr 2005 14:00:31 +0200, "manolo"
wrote:

Perdón, que me he equivocado:

bien sea windows o sea web, que utilice la librería para acceder a la base
de datos.

Quería decir que utilice la librería para gestionar los datos, no para
que la capa de presentación acceda a la base de datos, que es distinto.

Pues antes estaba bien y ahora está mal.

Para gestionar los datos se debe de usar el SGBD y no una librería.

No debes de construir un procesador de archivos encima del SGBD.


Saludos

Hola,

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.

Un saludo.

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 13 Apr 2005 14:00:31 +0200, "manolo"
wrote:

Perdón, que me he equivocado:

bien sea windows o sea web, que utilice la librería para acceder a la
base
de datos.

Quería decir que utilice la librería para gestionar los datos, no para
que la capa de presentación acceda a la base de datos, que es distinto.

Pues antes estaba bien y ahora está mal.

Para gestionar los datos se debe de usar el SGBD y no una librería.

No debes de construir un procesador de archivos encima del SGBD.


Saludos

Manolo,

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. 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. Las vistas, a pesar de lo que
Alfredo diga, no son relevantes en nuestra discusión. Nótense que NO HE
DICHO que no es relevante lo que dijo Alfredo, lo cual es muy cierto en los
casos de permisos sobre columnas, pero para nuestra discusión de capas y
consultas, las vistas las puedes o no elegir. Da lo mismo.

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.

Por ejemplo, si negocio tuviese que grabar un usuario X y luego grabar en
otro lugar las propiedades Y del mismo usuario, negocio le dice a datos
"graba este usuario X", donde le entrega la informacion específica del
usuario y luego hace otra llamada a datos diciendo "graba las propiedades
Y", donde entrega la infromacion de las propiedades. Alguien podria
argumentar por que no hacer un solo metodo. Bueno, la idea es separar las
responsabilidades de cada elemento de tu aplicacion. Por un lado grabas
usuarios y por otro las propiedades. Negocio es el encargado de orquestar el
funcionamiento y datos es el encargado en cada tarea de ejecutar la tarea
especifica.

¿Por que la capa de datos no es la base de datos? Por que si vas a usar sql
dinamico, es la capa de datos la encargada de generarlo y luego, utilizando
MSDAAB o simplemente ADO.NET lo ejecutas. Si utilizas procedimientos
almacenados, es la capa de datos la encargada de poblar los parametros y
ejecutarlo.

Que son las entidades de negocio?. Es la forma de representar algun elemento
de tu aplicacion. En el caso del usuario, la entidad de negocio es una clase
con propiedades, con las propiedades del usuario que quieres grabar. Si
tienes una funcion BuscarUsuario, tu le entregas el id del usuario a la capa
de datos y esta te retorna la entidad. Puedes utilizar datasets como
entidades de negocio. En este tema HAY mucha documentacion de cual es la
mejor represenatcion de las entidades de negocio y cuando utilziar cada una.

Espero aclararte algunas dudas mas.

Patrick.

"manolo" escribió en el mensaje
news:

Hola,

Dios mío! la que se ha liado! Me gusta, de vez en cuando debería haber
una discusión así de fuerte para aprender todos un poco más. He estado

fuera

y no pude leer mensajes.

Yo utilizo sp en sql server por la razón de que se pueden compilar y

la

ejecución es más rápida, a parte de que en cada sp se pueden controlar los
datos que se insertan, como por ejemplo el formateo que hay que dar en
algunos casos a algunos campos.
En cuanto a utilizar sp o querys creo que todos teneis algo de razón,
por ejemplo, utilizando consultas directamente se pueden leer más variedad
de datos, como por ejemplo: consultar todos los clientes de una zona,
consultar los clientes que son empresa, consultar los clientes de una
población en concreto, consultar todos los clientes que tengan fax, etc,

ya

que haría falta una función específica para cada consulta, mientras que

veo

más factible que para leer un registro de la tabla clientes y

actualizarlo,

crearlo y eliminarlo veo mejor utilizar un sp, ya que tendría un control

más

preciso y omogéneo sobre los datos. Utilizando sp, si tengo que hacer

alguna

modificación o restricción a la hora de insertar un dato en un campo, con
hacerlo en el sp ya lo implementarían todas las aplicaciones.

No soy experto en el tema, he estado leyendo multitud de libros,
tutoriales, etc, que por cierto, uno de los que me ha gustado más y no

tiene

que ver nada con las capas, es el de Fernando G. Guerrero (Sql server a
fondo, creo que se llama), y siempre hay controversia entre 2, 3 o 4

capas.

Según me recomendais, es que haga la capa de presentación y la capa
empresarial, pero discutís a cerca de consultar los datos por sp que por
sentencias, pero el final son 3 capas: sql server, librería abstracta con
funciones de acceso al sistema gestor de bases de datos y una última capa,
bien sea windows o sea web, que utilice la librería para acceder a la base
de datos.

Gracias a Carlos, Alfredo, Eduardo, Braulio, etc... que me han ayudado
mucho en cuanto a decisión. Un saludo.