Arquitectura en 3 capas, para expertos

Lazaro jejejeje, me aclaraste varias cosas a mi que no imaginaba sobre el
tema de capas jeje, bueno hoy aprendi algo mas!!!
Saludos
Pablo.

PD: espero no haber confundido al amigo con mi pobre explicacion de lo que
imagino por capas jejeje, bueno, por ahora seguire con mis numeritos en los
Tag , saludos !



"Lázaro" wrote in message
news:

Es bastante delicado tomar una decisión acertada.

Lo primero que tienes que evaluar es si tu aplicación es distribuida, o

sea

si tienes diferentes componentes que se ejecutan en máquinas separadas,
imáginate un objeto en un servidor de aplicaciones, otro componente en un
servidor web, etc...Si esta es la arquitectura está claro que deberías
construir en n-capas.

Lo segundo que tienes que mirar es si tu aplicación es para múltiples
clientes, o si siendo para un cliente es posible que en el futuro cambien
determinadas reglas de negocio. Si fuera así, entonces las n-capas también
te pueden ayudar, ya que como bien te han dicho, modificarías la regla u
otro objeto y sólo tienes que distribuir esa parte.

Y la tercera, es analizar si para los administradores de sistemas de donde
se vaya a implantar es mejor tener los componentes en un solo sitio y
controlados. Imaginate que tienes 500 usuarios, es posible que si pones

una

aplicación de 2 capas, cada cliente tenga que saber concretamente como
conectar y con que datos al servidor, quizás al personal de sistemas le
interesa más que los clientes se conecten a un objeto remoto que será el
único que sabe donde está la BD u otras fuentes de información.

El tema de tener divididas las reglas de los formularios, o de negocio, o

un

interface a la BD, es más una técnica de programación que te quitará

trabajo

en el mantenimiento, que la traducción de la arquitectura en capas. O sea
puedes tener esa división en reglas, formularios, etc... y ejecutar en
cliente/servidor de 2 capas.

Si vas a hacer una aplicación .NET en WebForms, por ejemplo, lo más
importante para que el rendimiento sea bueno es la velocida de ejecución

de

las peticiones, y los datos que manejan. Si por ejemplo ahí, para validar

un

dato tienes que instanciar otra DLL, aunque sea en el mismo servidor,
estarías penalizando el Site cuando tengas muchos usuarios.

Mi consejo, si la aplicación es distribuida, o sea si usa fuentes

externas,

o parte de la aplicación está en un servidor y otra parte en otro. Usa
n-capas. Si no, escribe tú código de la manera más flexible y cómoda para
realizar el mantenimiento.

No sé si te habré ayudado

Salu2

"Zeus" wrote in message
news:3d4d01c47298$7043e630$
Hola, voy a realizar un nuevo proyecto en VB .Net (una
típica facturación, pedidos, albaranes y facturas de
compras y ventas), bueno he oído hablar de la
arquitectura de tres capas o n capas, me he puesto a
buscar información y he encontrado en MSDN, y te explica
las distinta capas: IU, la lógica de aplicación o
negocio y la de los datos. Todo lo entiendo en la teoría
pero no lo veo en la práctica, como se comunica IU con la
capa de la lógica del negocio o aplicación, está claro
que en la capa de aplicación mediante lo clase de ADO.Net
y el gestor de base de datos es el encargado de
comunicarse entre estas dos capas. Estoy dando un
cursillo de ASP. Net y he visto los servicios Web, esto
se podría decir que la IU a realizar llamadas a los
servicio Web es la comunicación entre esta dos capas, es
decir, Una capa es la IU y la otra capa (lógica del
negocio) es la parte de la aplicación realizada en los
servicios Web. Si no me equivoco esto es lo que propone
Microsoft como arquitectura a la hora de diseñar o crear
un proyecto.

¿Estoy encaminado o lo he entendido mal?
¿Me aconsejáis que realice mi aplicación en esta
arquitectura?
¿O es mejor en dos capas cliente/servidor para este tipo
de proyecto para no complicarme?
Solo quiero que me aconsejéis, hablarme más sobre esta
arquitectura e indicarme donde puedo haber algún ejemplo
simple de una aplicación entre capas (código fuente, me
da igual que sea C# o VB .net) ya que en la práctica se
ve mejor todo lo que se dice en la teoría. También donde
podría encontrar más información sobre esta arquitectura.

Un saludo
Zeus

te recomiendo que busques en el historial de respuestas,
aca una de las tantas respuestas respecto a este tema.

http://www.google.cl/groups?hl=es&a...as%2Bgroup:microsoft.public.es.dotnet.vb%26hl%3Des%26lr%3D%26ie%3DUTF-8%26selm%3DOc5OPVgDEHA.3236%2540TK2MSFTNGP09.phx.gbl%26rnum%3D1

Saludos
-
Freddy Cáceres
Santiago - Chile

Hola, voy a realizar un nuevo proyecto en VB .Net (una
típica facturación, pedidos, albaranes y facturas de
compras y ventas), bueno he oído hablar de la
arquitectura de tres capas o n capas, me he puesto a
buscar información y he encontrado en MSDN, y te explica
las distinta capas: IU, la lógica de aplicación o
negocio y la de los datos. Todo lo entiendo en la teoría
pero no lo veo en la práctica, como se comunica IU con la
capa de la lógica del negocio o aplicación, está claro
que en la capa de aplicación mediante lo clase de ADO.Net
y el gestor de base de datos es el encargado de
comunicarse entre estas dos capas. Estoy dando un
cursillo de ASP. Net y he visto los servicios Web, esto
se podría decir que la IU a realizar llamadas a los
servicio Web es la comunicación entre esta dos capas, es
decir, Una capa es la IU y la otra capa (lógica del
negocio) es la parte de la aplicación realizada en los
servicios Web. Si no me equivoco esto es lo que propone
Microsoft como arquitectura a la hora de diseñar o crear
un proyecto.

¿Estoy encaminado o lo he entendido mal?
¿Me aconsejáis que realice mi aplicación en esta
arquitectura?
¿O es mejor en dos capas cliente/servidor para este tipo
de proyecto para no complicarme?
Solo quiero que me aconsejéis, hablarme más sobre esta
arquitectura e indicarme donde puedo haber algún ejemplo
simple de una aplicación entre capas (código fuente, me
da igual que sea C# o VB .net) ya que en la práctica se
ve mejor todo lo que se dice en la teoría. También donde
podría encontrar más información sobre esta arquitectura.

Un saludo
Zeus

.

Hola, Zeus:

No hay que darse mala vida con las capas, ni con las definiciones
preestablecidas.

La intención detrás del concepto es separar los componentes en areas
funcionales. Las reglas del negocio, por ejemplo, no son sólo las normas de
validación de una factura; tambien incluyen como deben ser procesadas las
facturas, quién puede hacerlo y cuales efectos adicionales produce dicho
proceso.

La idea primaria es separar las formas de los procesos, y los procesos de
los proveedores de datos específicos.

Lo que se busca es que si un día decides pasar tu aplicación de escritorio a
ASP, puedas reciclar todos los componentes funcionales, y solo debas
reemplazar tus formas (nivel de usuario) por paginas Web (nivel de usuario).

Dónde coloques tus componentes tambien es un problema secundario. Puedes
tener una aplicación en tres capas contenida en un solo EXE escrito en "C"
viejo para MS-DOS (aunque esto, claro está, no es lo típico).

El nivel de abstracción de los datos te viene dado por ADO.Net: en teoría,
si usas la interfaz OleDB, debería bastar con cambiar el string de conexión
de los objetos Connection para poder adaptarte a cualquier proveedor OleDB
disponible. En la práctica, sin embargo, a menos que limites tu uso de SQL
al mínimo soportado por todos los proveedores (es posible hacerlo, con uno
que otro truco y un gran desperdicio de capacidad); probablemente
necesitarás un nivel adicional de abstracción, responsable de convertir los
requerimientos de acceso al dialecto de SQL que hable cada servidor (no hay
dos SGBD que implementen el JOIN con la misma sintaxis, por ejemplo). Pero
no hay ningún problema en que las entidades (objetos de negocio: documentos,
clientes, productos; validadores o controladores, etcétera) "hablen"
directamente con la interfaz de acceso a datos. En un tiempo decidí separar
mis clases de negocio en una clase principal (Clientes, por ejemplo) y un
almacen (AlmacenClientes): no gané nada, y se me complicó supremamente el
mantenimiento de los sistemas. Ya no lo hago más.

Las "reglas de negocio" en realidad son mucho más que eso: son el *MODELO*
del sistema. Tienes entidades, que mencioné de pasada en el párrafo
anterior, y que son todas las clases de objetos (objetos reales, documentos,
eventos del negocio) que interactúan en tu sistema. Estas entidades
normalmente se dividen en dos tipos: clases de dominio -comunes a todas las
aplicaciones de un tipo que escribas- y clases de aplicación -especificas de
una aplicación en particular. La mayoría de las entidades pertenecen al
dominio (Sistemas Admnistrativos, por ejemplo); un ejemplo de clase de
aplicación podría ser una oferta o promoción. Luego tienes otras clases
(generalmente de aplicacion), responsables de "comunicar" a los componentes
de interfaz de usuario con los componentes del modelo. Estas clases son de
dos tipos: Validadores y Controladores.

Un Validador es el responsable de determinar la corrección de los datos
introducidos por el usuario. Normalmente tienes un validador por cada tipo
de entidad del sistema. Si tienes una forma para la edición de facturas, por
ejemplo, tendrás un Validador de facturas. La forma convierte los datos
contenidos en ella en un "paquete" (en el caso de la factura estará formado
por un encabezado y una colección de detalles), pasa el paquete al
validador. Si el validador determina que hay algún error, la forma lo
advertirá al usuario y éste podrá corregirlo. Si no hay ningún error, la
forma creará un Controlador, le pasará el paquete y le pedirá que ejecute el
proceso. Un validador es "más próximo a la interfaz" que un Controlador.

Si en un momento dado la aplicación debe ser ejecutada en una interfaz Web,
el componente ASP recibirá la solicitud del usuario, ensamblará un paquete
(exactamente igual al que se generaba en la version de WinForms) y llamará
al Validador y al Controlador.

Entonces, las tres capas son: la interfaz de usuario, el modelo del negocio
(el sistema en si) y el nivel de acceso a datos, cuya responsabilidad no es
lidiar con cada clase del sistema, sino convertir requerimientos funcionales
en instrucciones digeribles para el proveedor de datos específico.

Los componentes del modelo de negocios pueden estar contenidos en el mismo
ejecutable de la interfaz, en una o varias DLL en el equipo del usuario, o
en un equipo remoto, al que puedes acceder utilizando Remoting o
implementarlos como servicios Web.

La recomendación es que implementes cada componente de la manera mas
independiente posible, de modo que puedas cambiar la manera en que se
distribuye con un mínimo de impacto en la estructura general de tu
aplicación. Los modelos de n-capas afectan tanto al diseño conceptual del
sistema como al diseño físico (deployment), pero cada categoría es
independiente de las otras.

Salud!

Leonardo
[MVP Visual Basic]
leonardo<arroba>mvps<punto>org

"El presente es una luz que palpita entre dos tinieblas"
- Naguib Mahfuz

Hola, me lo puedes enviar?

veletapgARROBAwanadooPUNTOcom


"Codigo47" escribió en el mensaje
news:exy$
que te metes chavon ?, no te das cuenta que el falco DJ_MIAO, entro al foro, leyo el asunto de Zeus
y no solo no lo contestó sino que se puso a insultarlo porque no comprendia algo !!!!!!!. Esa fue la
falta de respeto.

Y para no irme de tema, Zeus te paso una solución que vi en una charla de un señor que se llama
Angel "Java" Lopez:

La idea es esta:



La capa de ENIDADES EMPRESARIALES es esto:

Public Class Cliente
Dim mIDCliente As Integer
Dim mRazonSocial As String
Dim mEmail As String

Public Property IDCliente() As Integer
Get
Return mIDCliente
End Get
Set(ByVal Value As Integer)
mIDCliente = Value
End Set
End Property

Public Property RazonSocial() As String
Get
Return mRazonSocial
End Get
Set(ByVal Value As String)
mRazonSocial = Value
End Set
End Property

Public Property EMail() As String
Get
Return mEmail
End Get
Set(ByVal Value As String)
mEmail = Value
End Set
End Property
End Class

Fijate que es una clase simple, solo con propiedades, que son ni mas ni menos que los datos que
tengas en la tabla Clientes en la base de datos de tu proyecto. Crea clases para todas las entidades
que deba manejar el sistema.

CAPA DE PRENSENTACION, Formularios o Paginas web ASP, el resto de las capas no cambia para
cualquiera de estas dos formas de presentacion.

CAPA DE ACCESO A DATOS: en esta capa van a existir clases para guardar los datos de las clases de
Entidades Empresariales en la base de datos, lo que se llama mapear:

Imports CapaEntidadEmpresarial

Public Class MapeoCliente
Public Function Agregar(ByVal Cliente As Cliente) As Integer

End Function

Public Sub Modificar(ByVal Cliente As Cliente)

End Function

Public Sub Borrar(ByVal IDCliente As Integer)

End Function

Public Function Buscar(ByVal Cliente As Cliente) As ColeccionCliente

End Function
End Class

Fijate que las funciones de esta clase reciben una Entidad Empresarial (Cliente) y la guardan en la
base de datos (je saque el codigo que guarda en la base porque es bastante confuso para explicar
"capas").

En la funcion AGREGAR escribir codigo para que tome los datos del objeto Cliente y los guarde en la
base, con SQL embebido ("insert into Cliente...") para Access o MySQL o con una llamada a un Store
Procedure, si usas SQL Server, Oracle o DB2.

Tambien mira la funcion Buscar, esta funcion recibe un objeto Cliente y usando SQL o un Store
Procedure, busca los datos en la base u los devuelve en una coleccion de objetos Cliente, las
colecciones las armo asi:

Public Class ColeccionCliente
Inherits System.Collections.CollectionBase

Public Sub Add(ByVal Objeto As Cliente)
list.Add(Objeto)
End Sub

Public Sub Remove(ByVal Index As Integer)
If Index > Count - 1 Or Index < 0 Then
Throw New System.Exception("Índice de Colección Inválido")
Else
List.RemoveAt(Index)
End If
End Sub

Public ReadOnly Property Item(ByVal index As Integer) As Cliente
Get
Return CType(List.Item(index), Cliente)
End Get
End Property
End Class

se hereda de la clase CollectionBase que es una coleccion base que viene en el Framework, para poder
implementar una coleccion que solo acepte objetos de tipo Cliente, si se usas un arraylist, se
pueden agregar cualquier tipo de Objetos, por eso uso este tipo de coleccion. Ademas que me parece
una manera muy efectiva para la comunicacion entra las capas, fijate que el unico que conoce el
nombre de los campos de la base de datos y como llegar a ellos es la Capa de Acceso a Datos, y
ninguna otra !.
Esta Coleccion de objetos Cliente la declaro en la Capa de Entidades Empresariales.

La CAPA DE SERVICIOS: es una capa intermedia entre la presentacion y el acceso a datos, y la funcion
es justamente aislar a la presentacion del acceso a datos, para que, cualquier cambio que se realize
en el acceso a datos no se vea reflejado en la presentacion y sea "amortiguado" por esta capa de
servicios:

Public Class ServicioCliente
Public Sub AgregarCliente(ByVal Cliente As Cliente)
Dim M As New MapCliente()

M.Conectar()

M.Agregar(Cliente)

M.Desconectar()
End Sub

Public Function BuscarCliente(ByVal Cliente As Cliente) As ColeccionCliente
Dim M As New MapCliente()

M.Conectar()

BuscarCliente = M.Buscar(Cliente)

M.Desconectar()
End Function
End Class

El codigo de esta capa es solamente tomar los datos que le manda la presentacion, gestionar cuando
debe conectar a la base de datos, llamar a la capa de acceso a datos para que guarde los datos que
vienen de la capa de presentacion y desconectarse de la base de datos.

Mirando el grafico, nos damos cuenta que cada flecha de una capa a otra significa REFERENCIA en VB
.Net, esto es, tenemos UNA solucion con 4 proyectos, uno por cada Capa, el proyecto la Capa
Presentacion va a tener referencia al proyecto de la Capa de Entidades Empresariales, al igual que
el de la Capa de Servicios, y la Capa de Acceso a Datos. Ademas la Capa de Serivicios va a tener
referencia a el proyecto de la Capa de Acceso a Datos.

Para despejar cualquier mal explicacion, les dejo una solucion de ejemplo que trata de implementar
esta arquitectura, esta hecho con access. Si se hiciera con SQL Server el codigo en la capa de
acceso a datos se reduce mucho !.
Es una pequeña aplicacion que la uso para registrar el analisis de un nuevo sistema o los errores en
los programas que me envian los clientes. A los errores los llame "situaciones", ya que no solo
registros eso, sino tambien nuevos agregados, analisis, cosas que debo hacer, preguntas que yo tengo
que hacerle a los clientes, etc. La idea es que todo lo referente a los sistemas que desarrollo este
guardado en este sistemita.

Problemas de ultimo momento, no lo puedo adjuntar, si me mandan un mail se los envio !

saludos !.

Codigo47
Analista en Sistemas
Argentina, Buenos Aires

ok,muy bueno lo tuyo. Me presento, me llamo Fernando Anastasía, soy
Argentino viviendo en Almería(España). Me parece muy bueno tu aporte al
foro, siempre estas solucionando los problemas. Me gusto mucho esto de las 3
capas ya que me aclaro algunas lagunas que tenia por ahi.
Te dejo mi mail , , en cuanto puedas me
envias el programita que tienes. Gracias
fernando

"Codigo47" escribió en el mensaje
news:exy$
que te metes chavon ?, no te das cuenta que el falco DJ_MIAO, entro al foro,
leyo el asunto de Zeus y no solo no lo contestó sino que se puso a
insultarlo porque no comprendia algo !!!!!!!. Esa fue la falta de respeto.

Y para no irme de tema, Zeus te paso una solución que vi en una charla de un
señor que se llama Angel "Java" Lopez:

La idea es esta:



La capa de ENIDADES EMPRESARIALES es esto:

Public Class Cliente
Dim mIDCliente As Integer
Dim mRazonSocial As String
Dim mEmail As String

Public Property IDCliente() As Integer
Get
Return mIDCliente
End Get
Set(ByVal Value As Integer)
mIDCliente = Value
End Set
End Property

Public Property RazonSocial() As String
Get
Return mRazonSocial
End Get
Set(ByVal Value As String)
mRazonSocial = Value
End Set
End Property

Public Property EMail() As String
Get
Return mEmail
End Get
Set(ByVal Value As String)
mEmail = Value
End Set
End Property
End Class

Fijate que es una clase simple, solo con propiedades, que son ni mas ni
menos que los datos que tengas en la tabla Clientes en la base de datos de
tu proyecto. Crea clases para todas las entidades que deba manejar el
sistema.

CAPA DE PRENSENTACION, Formularios o Paginas web ASP, el resto de las capas
no cambia para cualquiera de estas dos formas de presentacion.

CAPA DE ACCESO A DATOS: en esta capa van a existir clases para guardar los
datos de las clases de Entidades Empresariales en la base de datos, lo que
se llama mapear:

Imports CapaEntidadEmpresarial

Public Class MapeoCliente
Public Function Agregar(ByVal Cliente As Cliente) As Integer

End Function

Public Sub Modificar(ByVal Cliente As Cliente)

End Function

Public Sub Borrar(ByVal IDCliente As Integer)

End Function

Public Function Buscar(ByVal Cliente As Cliente) As ColeccionCliente

End Function
End Class

Fijate que las funciones de esta clase reciben una Entidad Empresarial
(Cliente) y la guardan en la base de datos (je saque el codigo que guarda en
la base porque es bastante confuso para explicar "capas").

En la funcion AGREGAR escribir codigo para que tome los datos del objeto
Cliente y los guarde en la base, con SQL embebido ("insert into Cliente...")
para Access o MySQL o con una llamada a un Store Procedure, si usas SQL
Server, Oracle o DB2.

Tambien mira la funcion Buscar, esta funcion recibe un objeto Cliente y
usando SQL o un Store Procedure, busca los datos en la base u los devuelve
en una coleccion de objetos Cliente, las colecciones las armo asi:

Public Class ColeccionCliente
Inherits System.Collections.CollectionBase

Public Sub Add(ByVal Objeto As Cliente)
list.Add(Objeto)
End Sub

Public Sub Remove(ByVal Index As Integer)
If Index > Count - 1 Or Index < 0 Then
Throw New System.Exception("Índice de Colección Inválido")
Else
List.RemoveAt(Index)
End If
End Sub

Public ReadOnly Property Item(ByVal index As Integer) As Cliente
Get
Return CType(List.Item(index), Cliente)
End Get
End Property
End Class

se hereda de la clase CollectionBase que es una coleccion base que viene en
el Framework, para poder implementar una coleccion que solo acepte objetos
de tipo Cliente, si se usas un arraylist, se pueden agregar cualquier tipo
de Objetos, por eso uso este tipo de coleccion. Ademas que me parece una
manera muy efectiva para la comunicacion entra las capas, fijate que el
unico que conoce el nombre de los campos de la base de datos y como llegar a
ellos es la Capa de Acceso a Datos, y ninguna otra !.
Esta Coleccion de objetos Cliente la declaro en la Capa de Entidades
Empresariales.

La CAPA DE SERVICIOS: es una capa intermedia entre la presentacion y el
acceso a datos, y la funcion es justamente aislar a la presentacion del
acceso a datos, para que, cualquier cambio que se realize en el acceso a
datos no se vea reflejado en la presentacion y sea "amortiguado" por esta
capa de servicios:

Public Class ServicioCliente
Public Sub AgregarCliente(ByVal Cliente As Cliente)
Dim M As New MapCliente()

M.Conectar()

M.Agregar(Cliente)

M.Desconectar()
End Sub

Public Function BuscarCliente(ByVal Cliente As Cliente) As
ColeccionCliente
Dim M As New MapCliente()

M.Conectar()

BuscarCliente = M.Buscar(Cliente)

M.Desconectar()
End Function
End Class

El codigo de esta capa es solamente tomar los datos que le manda la
presentacion, gestionar cuando debe conectar a la base de datos, llamar a la
capa de acceso a datos para que guarde los datos que vienen de la capa de
presentacion y desconectarse de la base de datos.

Mirando el grafico, nos damos cuenta que cada flecha de una capa a otra
significa REFERENCIA en VB .Net, esto es, tenemos UNA solucion con 4
proyectos, uno por cada Capa, el proyecto la Capa Presentacion va a tener
referencia al proyecto de la Capa de Entidades Empresariales, al igual que
el de la Capa de Servicios, y la Capa de Acceso a Datos. Ademas la Capa de
Serivicios va a tener referencia a el proyecto de la Capa de Acceso a Datos.

Para despejar cualquier mal explicacion, les dejo una solucion de ejemplo
que trata de implementar esta arquitectura, esta hecho con access. Si se
hiciera con SQL Server el codigo en la capa de acceso a datos se reduce
mucho !.
Es una pequeña aplicacion que la uso para registrar el analisis de un nuevo
sistema o los errores en los programas que me envian los clientes. A los
errores los llame "situaciones", ya que no solo registros eso, sino tambien
nuevos agregados, analisis, cosas que debo hacer, preguntas que yo tengo que
hacerle a los clientes, etc. La idea es que todo lo referente a los sistemas
que desarrollo este guardado en este sistemita.

Problemas de ultimo momento, no lo puedo adjuntar, si me mandan un mail se
los envio !

saludos !.

Codigo47
Analista en Sistemas
Argentina, Buenos Aires