Las famosas n capas.

Eduardo,

tu crees que esta discusión va para algun lado?.

Patrick.

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

¿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/

tu crees que esta discusión va para algun lado?.

Aparentemente no. Ya no le voy a discutir nada pero me interesa saber como
lo resolveria el, porque nunca esta demas ver algo diferente. Es una manera
de aprender.

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

"Alfredo Novoa" escribió en el mensaje

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.

Podrías definir 'sistema'?

Hola Alfredo,

Creo que me he explicado mal.

El fin de crear la librería es poder reutilizarla para distintos fines:
esta aplicación se utilizará en un restaurante donde habrá una aplicación en
un pc con un interface tpv, otro equipo en una oficina donde se gestionarán
artículos, facturas, etc, un ppc con otro tpv y en un futuro el cliente
quiere poder ver la facturación del restaurante a distancia, por lo cual he
pensado en una página asp.net.
El inicio del hilo era saber si esta forma de proceder es la correcta ya
que en todo lo que he leido cada uno cuenta como le va, y creeme, que tu
visi´ón, la de Eduardo, la de Carlos y la de Braulio me ha servido de mucho.
Ahora me toca pelear con el código, ya que es mi primer proyecto en
vb.net serio y me va a tocar incar los codos :)

Un saludo.

"Alfredo Novoa" escribió en el mensaje
news:

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

Hola Patric,

Muchas gracias por la aclaración, voy a leer el enlace que me has dejado
en el otro mensaje.

Muchas gracias.

"Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
news:edJ$

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.