Ir al contenido principal

APLICACIONES N-CAPAS EN VISUAL NET

"AÑO DEL DIALOGO Y RECONCILIACIÓN NACIONAL"

FACULTAD DE INGENIERÍA DE SISTEMAS Y TELEMATICA

CURSO:
PROGRAMACIÓN III.

TEMA:
APLICACIONES N-CAPAS EN VISUAL NET.

DOCENTE:
PORRO CHULLI MARCO AURELIO.


INTEGRANTES:
JAN CHISQUIPAMA PILCO
ROMMEL ROLANDO CHAMIK KAYAJUIS
GEDIONI DEKENTAI UJUKAM

CICLO:
V-A


BAGUA GRANDE - UTCUBAMBA 
AMAZONAS
2018











DEFINICIÓN

En el modelo de acceso a datos, una capa es un nivel lógico en el cual residen componentes o aplicaciones lógicas. Las capas pueden residir en uno a mas equipos o servidores, el número de capas hace referencia al número de niveles y no al número de equipos en los cuales los servicios son divididos. Las capas que generalmente se incluyen en aplicaciones son:
  1. Capa de Cliente: conocida como capa de Presentación es la que contiene las interfaces en las que el usuario interactua con el sistema.
  2. Capa de la Lógica de Negocios: el cual contiene la lógica que interactua con el origen de datos. Esta capa intermedia contiene la parte de la aplicación que interactua con los datos, por ejemplo: la creación de una cadena de conexión al origen de datos.
  3. Capa de acceso a Datos: la cual se relaciona directamente con el origen de datos
Beneficios del trabajo con Capas
  • Escalabilidad en las aplicaciones
  • Distribución mas efectiva
  • Cambios en la aplicaciones mas sencillos de manejar e implementar
  • Separación de funciones
  • Permite aplicaciones en diferentes sistemas operativos
  • Clientes menos pesados (thin Client)


La Arquitectura de N-capas es probablemente uno de los modelos más utilizados en programación. Se utiliza tan a menudo porque es escalable, extensible, segura, fácil de mantener en el tiempo, reutilizable y se puede trabajar por diferentes programadores según su especialidad sin interferirse el trabajo.

En este artículo voy a presentar una arquitectura básica de n-capas que se puede utilizar para la creación de pequeñas hasta grandes aplicaciones.

Para el desarrollo de una arquitectura en capas robusta y perdurable en el tiempo, se deben tener en cuenta los siguientes aspectos:

·         Las capas de una aplicación deben ser independientes entre sí, como las fichas de un lego. De esta manera podemos reemplazar cualquiera de las capas por una más actualizada en cualquier momento.
·         Se debe mantener el principio de responsabilidad modular, esto quiere decir que cada capa es responsable de un tema o característica.
·         Principio de caja negra. Cada componente es independiente de otros y solo interactúa en sus entradas y salidas.
·         Don't Repeat Yourself (DRY). Principio de No repitas. Cada funcionalidad debe estar una sola vez en el sistema (Sin duplicados).
·         Establecer normas en la codificación del desarrollo. Esto asegura la consistencia de código y el mantenimiento del mismo.









MÉTODO DE CONSTRUCCIÓN DE COMPONENTES EN LA IMPLEMENTACIÓN DE CAPAS

   La construcción de aplicaciones n-tier (n-capas) distribuidas ha emergido como la arquitectura predominante para la construcción de aplicaciones multiplataforma en la mayor parte de las empresas.

   Este cambio radical en los modelos de computación, desde los sistemas monolíticos basados en mainframe y los tradicionales sistemas cliente-servidor, hacia sistemas distribuidos multiplataforma altamente modularles, representa el desarrollo rápido y avance de la investigación en el mundo del desarrollo de aplicaciones, tal y como se pone de manifiesto en las últimas tendencias de las grandes empresas de tecnología, como Sun con su estrategia Sun One, o Microsoft con DotNET (.Net).

El modelo presenta algunas ventajas entre ellas:

  •     Desarrollos paralelos (en cada capa)

  •     Aplicaciones más robustas debido al encapsulamiento

  •   Mantenimiento y soporte más sencillo (es más sencillo cambiar un componente que modificar una aplicación monolítica)

  •    Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad)

  •   Alta escalabilidad. La principal ventaja de una aplicación distribuida bien diseñada es su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo más hardware. El crecimiento es casi lineal y no es necesario añadir más código para conseguir esta escalabilidad.

   Como tecnología, las arquitecturas de n-capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver complejos problemas inmersos en cambios constantes.

    Todas las aplicaciones basadas en n-capas permitirán trabajar con clientes ligeros, tal como navegadores de Internet, WebTV, Teléfonos Inteligentes, PDAs (Personal Digital Assistants o Asistentes Personales Digitales) y muchos otros dispositivos preparados para conectarse a Internet.

    De este modo, las arquitecturas de n-capas se están posicionando rápidamente como la piedra angular de los desarrollos de aplicaciones empresariales y las compañías están adoptando esta estrategia a una velocidad de vértigo como mecanismo de posicionamiento en la economía emergente que tiene su base en la red (lo que se ha venido a denominar "Nueva Economía").

    Actualmente, la Red (Internet, intranets y extranets) es el ordenador o, como diría Sun Microsystems, el ordenador es la Red. Este paradigma está creando un cambio fundamental en los modelos de computación que, a su vez, proporciona desafíos y oportunidades como nunca antes había se habían producido.

   Realmente, los componentes distribuidos de una arquitectura de n-capas es una tecnología esencial para crear la siguiente generación de aplicaciones e-business, aplicaciones que son altamente escalables, fiables y que proporcionan un alto rendimiento y una integración sin fisuras con los sistemas de back-end heredados.

     A diferencia de lo que se pudiera pensar, el desarrollo en n-capas no es un producto o un estándar, es un concepto estratégico que ayuda a la construcción y despliegue lógico de un sistema distribuido. Los sistemas de n-capas subdivididos ayudan a facilitar el desarrollo rápido de aplicaciones y su posterior despliegue, con beneficios incrementales fruto de los esfuerzos del desarrollo en paralelo coordinado y del outsourcing inteligente, resultando un enorme decremento del tiempo de desarrollo y de sus costes. Muchas de las aplicaciones de e-business que se utilizan actualmente simplemente utilizan un navegador de Internet como cliente ligero que implementa una interfaz universal. Una arquitectura basada en clientes ligeros desplaza la capa de presentación de la aplicación en el lado del cliente, mientras que la lógica de negocio y los datos residen en el middleware y los servidores de back-end. El diseño para clientes ligeros minimiza los problemas de despliegue de las aplicaciones, mientras que maximiza la accesibilidad a la misma desde una amplia variedad de plataformas heterogéneas. Los frameworks basados en n-capas se crean para obtener las ventajas de los estándares abiertos de la industria que permiten a las aplicaciones resultantes operar en entornos distribuidos multiplataforma.








 CAPA DE MANEJO DE DATOS

La capa de negocios o de manejo de datos, es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina también capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse.

Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.
División de la capa de manejo de datos
La capa de negocios representa el grueso de la lógica de funcionamiento de la aplicación distribuida. En esta capa se sitúan las normas de acceso a datos, la lógica de tratamiento de los mismos, y en general cualquier elemento de la aplicación que pueda reutilizarse. El objetivo de la creación de esta capa “intermedia” es aislar la capa de presentación de la capa de servidor, de forma que las estructuras de datos subyacentes y la lógica que las utilizan sean independientes de la capa de presentación. De esta forma, también, el mantenimiento de las normas de negocio será más sencillo y, sobre todo, será reutilizable desde cualquier capa de presentación, sea del tipo que sea.
A pesar de que se suele utilizar el nombre de capa de negocios para referenciar a todos los elementos que componen esta capa intermedia de software, por lo general la capa de negocios suele dividirse en dos tipos de elementos, atendiendo a la función que desempeñan en la capa.

   Lógica de negocios
Cuando las aplicaciones adquieren cierto volumen o las entidades implicadas tienen cierta complejidad, la lógica de acceso a datos por sí sola no es suficiente para encapsular convenientemente el acceso a las entidades de datos. En estos casos será necesario añadir objetos más complejos que a su vez encapsulen los objetos de acceso a datos y los expongan de forma más sencilla a las capas superiores, facilitando su manejo.
Además, en las aplicaciones
distribuidas con cierto tamaño es frecuente encontrar reglas de negocio que no tienen nada que ver con el acceso a datos, sino que constituyen mecanismos aparte que de una forma o de otra es deseable extraer de la capa de presentación para su reutilización o para que su mantenimiento sea sencillo.
Estas necesidades implican a menudo la creación de una capa adicional de lógica que llamaremos lógica de negocios. Los elementos de la lógica de negocios ya no se conectan a los orígenes de datos ni representan a las entidades de datos subyacentes, sino que utilizan los objetos de acceso a datos y las entidades de negocio, siendo pues una especie de “cliente” de la lógica de acceso a datos.

  Lógica de acceso a datos
La lógica de acceso a datos incluye los elementos necesarios para que la aplicación se conecte a orígenes de datos y recupere estructuras de datos que serán utilizadas por el resto de la aplicación. En una aplicación distribuida, los únicos elementos que se conectan a la base de datos son los objetos de acceso a datos, y el resto de elementos de la aplicación se limitan a enlazar con estos objetos para solicitar datos y enviar órdenes a los orígenes de datos.
Los motivos para encapsular todo el acceso a datos en la lógica de acceso a datos son múltiples. En primer lugar, no será necesario distribuir la información de conexión por todo el sistema, ya que el único punto desde el que se efectuará el acceso directo a los orígenes de datos será el equipo en el que resida físicamente la lógica de acceso a datos. Tampoco será necesario distribuir el software cliente del SGBD por diferentes máquinas, lo que facilita el mantenimiento y la instalación de la aplicación.

Además, encapsular la lógica de acceso a datos permite que la aplicación sea agnóstica respecto al origen de datos, es decir, puede realizar sus tareas sin tener la necesidad de saber en qué SGBD concreto residen los datos, ni en qué punto de la red se halla el servidor, lo que facilita la configuración del sistema. Este sistema posibilita la utilización de varios SGBD en una aplicación o facilita la migración de un SGBD a otro. También permite que la aplicación ignore la estructura real de los orígenes de datos, ya que es la propia lógica de acceso a datos la que expondrá las estructuras con las que trabajará la aplicación, acomodándolas a las necesidades de la misma.
Otro factor importante es la reutilización. La separación de esta lógica permite reutilizar los componentes de acceso a datos en diversas aplicaciones sin necesidad de copiar el código y manteniendo la coherencia en el comportamiento del acceso a datos en todas ellas.
A pesar de que otros elementos, como los que componen la lógica de negocios, son opcionales, los elementos de lógica de acceso a datos deben estar presentes en toda arquitectura distribuida que se diseñe, debido a las ventajas que aportan.









CAPA DE NEGOCIOS

La capa lógica de negocios ocupa un lugar preeminente en la construcción de una infraestructura de software, al permitir el crecimiento y la extensión de servicios para todas las aplicaciones existentes y futuras.
La definición de los limites de cada capa nos permitirá definir correctamente la colaboración que proporcionará cada una de ellas y descubriremos que la capa intermedia es inevitablemente la lógica de negocios. Esto dará lugar a una infraestructura robusta y lista para la extensión y el crecimiento como proveedora de servicios.
Para la construcción de esta capa se emplearán los componentes tecnológicos más adecuados en cada caso.
En la capa de negocios se encuentra la parte básica de un programa, son los módulos que reciben mensajes de la capa de usuario y responden con resultados, el término negocio se refiere al intercambio de los datos, esta capa es importante para las cuestiones operativas, el modelado de los procesos se encuentra aquí, el programador a cargo de esta capa tienen la mayor responsabilidad.
La capa de negocio también se conoce como capa lógica, es el intermediario entre la capa de presentación y datos.



CAPA DE INTERFAZ DE USUARIO 

La capa de presentación o interfaz de usuario se refiere al mecanismo de interacción del usuario con el sistema.
Es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.

Los tipos de interfaces de software más comunes son las aplicaciones de ventanas y web. Los tipos de interfaces de hardware más comunes son el ratón, el teclado, el micrófono, pantallas táctiles, dispositivos de imagen y audio.
Está formada por los formularios y los controles que se encuentran en los formularios, capa con la que interactúan el usuario   y es responsable de obtener datos de la capa siguiente, mostrarlos, validar entradas de datos, enviarlas a la siguiente capa donde pueden dividirse en: presentación, código de interfaz de usuario.

La capa de presentación o interface de usuario la constituye el software con el que el usuario interactúa para operar con la aplicación. Es probablemente la parte más trabajosa de la misma, ya que es muy frecuente que aplicaciones cuyas reglas de negocio sean relativamente sencillas tengan en cambio un interfaz de usuario complejo y vistoso que le proporcione al usuario una experiencia de manejo fácil y agradable. Además, mientras que en la creación de reglas de negocio normalmente sólo interviene un tipo de programación, preferentemente basada en lenguajes, en la preparación del interfaz de usuario suelen mezclarse varias disciplinas, como el diseño o la usabilidad.

Un error frecuente en la creación de los interfaces de usuario consiste en olvidar que las reglas de negocio no se hallan en el interfaz, sino en los objetos subyacentes que residen en las capas inferiores de la solución. La capa de presentación no es más que un sistema de presentación y manejo de datos que se obtienen y se actualizan con los objetos de negocio comunes para todas las aplicaciones que los usan. Si se olvida este aspecto se puede caer en la tentación de colocar reglas de negocio en el interfaz de usuario, imposibilitando la reutilización de las mismas y complicando la distribución y despliegue de la aplicación. Por lo tanto, una regla de oro a observar en toda aplicación distribuida es que la capa de presentación ha de ser completamente independiente de las reglas de negocio, y su función se limitará a la presentación y manejo de los datos de la aplicación, que obtendrá mediante el uso de los objetos de la capa de negocios comentados en la sección anterior.

Esto convierte a la capa de presentación en una mera fachada de los procesos que son gestionados por la capa de negocios. Las capas de presentación suelen ser “delgadas”, es decir, contienen pocas líneas de código, ya que su función principal está cubierta por las características de los elementos “visuales” que las componen. Una tendencia creciente es la separación entre diseño y código, ya existente, por ejemplo, en las aplicaciones web dinámicas. 










RESUMEN


Las aplicaciones de datos con n niveles son aplicaciones de datos que se dividen en varios niveles. Las aplicaciones con n niveles, también denominadas "aplicaciones distribuidas" o "aplicaciones multinivel", dividen el procesamiento en niveles independientes que se distribuyen entre el cliente y el servidor. Al desarrollar aplicaciones que tienen acceso a datos, se debe realizar una separación clara entre los distintos niveles que constituyen la aplicación.

Una aplicación típica con n niveles incluye un nivel de presentación, un nivel intermedio y una capa de datos. La manera más fácil de separar los distintos niveles de una aplicación con n niveles es creando proyectos independientes para cada nivel que se desee incluir en la aplicación. Por ejemplo, el nivel de presentación podría ser una aplicación de formularios Windows Forms, mientras que la lógica de acceso a datos podría ser una biblioteca de clases ubicada en el nivel intermedio. Además, el nivel de presentación podría comunicarse con la lógica de acceso a datos del nivel intermedio a través de un servicio como un servicio. Al separar los componentes de la aplicación en niveles independientes, se aumenta la facilidad de mantenimiento y la escalabilidad de la aplicación. Esto se consigue mediante una integración más sencilla de nuevas tecnologías, que se pueden aplicar a un solo nivel sin necesidad de volver a diseñar la solución completa. Además, las aplicaciones con n niveles almacenan normalmente la información confidencial en el nivel intermedio, lo cual mantiene su aislamiento respecto del nivel de presentación.

                                                              SUMMARY

Data applications with n levels are data applications that are divided into several levels. Applications with n levels, also called "distributed applications" or "multilevel applications", divide the processing into independent levels that are distributed between the client and the server. When developing applications that have access to data, a clear separation between the different levels that constitute the application must be made.
A typical application with n levels includes a presentation level, an intermediate level and a data layer. The easiest way to separate the different levels of an application with n levels is to create independent projects for each level that you want to include in the application. For example, the presentation level could be a Windows Forms application, whereas the data access logic could be a class library located at the intermediate level. In addition, the presentation level could communicate with the data access logic of the intermediate level through a service as a service. By separating application components into separate levels, ease of maintenance and scalability of the application is enhanced. This is achieved through a simpler integration of new technologies, which can be applied to a single level without having to redesign the complete solution. In addition, applications with n levels normally store the confidential information at the intermediate level, which maintains its isolation from the presentation level.











RECOMENDACIONES:

  • Cada capa ofrece un conjunto de funciones para la capa superior y utiliza funciones de la capa inferior.Cada capa, en un nodo, se comunica con su igual en el otro nodo
  • La capa de negocios  o de manejo de datos, es donde residen los programas que se ejecutan, se reciben la peticiones del usuario y e envían la respuestas tras el proceso.
  • Es muy importante saber que la capa de manejo de datos se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él.









CONCLUSIONES:
  • Las controladoras ofrecen un mecanismo para reutilizar el control de los eventos de la capa de presentación. Hay que tener en claro que las clases del análisis tienen que ser mapeadas a clases de diseño. En el diseño, el Arquitecto toma en cuenta otras consideraciones para decidir la implementación de la lógica identificada en etapas iniciales.
  • La Arquitectura de de Microsoft para .NET muestra con claridad cómo diseñar e implementar nuestra capa de presentación, y cómo implementar la lógica de negocio mediante la separación de capas.
  • Las cuestiones de diseño están guiadas usualmente por preocupaciones por el rendimiento, despliegue, reutilización, etc, que dan origen a clases de De allí que tratar de mapear las clases de análisis directamente en clases de diseño puede resultar no tan ventajoso en la implementación.

APRECIACIÓN DEL EQUIPO:
  • Los diferentes procesos están distribuidos en capas físicas y lógicas, los procesos se ejecutan en diferentes equipos los cuales poseen una configuración distinta y está optimizado para realizar el papel que le ha sido asignado dentro de la  estructura de la aplicación.









GLOSARIO DE TÉRMINOS:

APLICACIÓN DISTRIBUIDA:
 Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor)

DNA: ( Distributed NextWork  Applications ) .

EJB: ( Enterprise Java Beanss ) de Sun Microsystem.

XML: ( Extensible Markup Languaje ) .

NET: De Microsoft que incluye nuevos lenguajes como Visual Basic.net.

CAPA: Puede ser a su vez, un nivel.





LINKOGRAFIA














Comentarios

Entradas populares de este blog

Subneteo de Redes

"Año  del Diálogo y la Reconciliación Nacional” CARRERA: Ing. Sistemas y Telematica ASIGNATURA: Tegnologia de Red I. DOCENTE: Marco Aurelio Porro Chulli TEMA: Subneteo de Redes INTEGRANTES: Gedioni Dekentai Ujukam Rommel R. Chamik Kayajuis. SUBNETEO DE RED "EL SUBNETEO",  es el acto de dividir las grandes  redes  en redes más pequeñas para que estas redes puedan funcionar mejor en cuanto a recepción y envio de paquetes a través de la  red  de la  internet . Este término es un término netamente utilizado en el campo de la Computación e Informática en la rama de las redes cuando se arma  una red  y se quiere dividir esta red en subredes. Un  objetivo  teórico del Subneteo es proporcionar mejor manejo de redes. A principios de 1996 estaban conectadas a Internet más de 25 millones de computadoras  en más de 180 países, y la cifra sigue en aumento ahora más que las computadoras se han vuelt...

Clase Swing - Gedioni

CLASE SWING DEFINICION: El paquete Swing es parte de la JFC (Java Foundation Classes) en la plataforma Java. La JFC provee facilidades para ayudar a la gente a construir GUIs. Swing abarca componentes como botones, tablas, marcos, etc... Las componentes Swing se identifican porque pertenecen al paquete  javax.swing . Swing existe desde la JDK 1.1 (como un agregado). Antes de la existencia de Swing, las interfaces gráficas con el usuario se realizaban a través de AWT (Abstract Window Toolkit), de quien Swing hereda todo el manejo de eventos. Usualmente, para toda componente AWT existe una componente Swing que la reemplaza, por ejemplo, la clase Button de AWT es reemplazada por la clase JButton de Swing (el nombre de todas las componentes Swing comienza con "J"). Las componentes de Swing utilizan la infraestructura de AWT, incluyendo el modelo de eventos AWT, el cual rige cómo una componente reacciona a eventos tales como, eventos de teclado, mouse, etc... Es por e...

Controles Swing Listas-Programacion

CO NTROLES SWING LISTAS CONTENIDO  DEFINICIÓN Es un componente que nos permite presentar una lista de selección donde podemos escoger uno o varios elementos, este tipo de selección ya la habíamos visto mediante el uso del componente Atómico   JComboBox , pero en ese para ver todos los elementos teníamos que desplegar el combo y solo podemos seleccionar de a una opción El paquete Swing es parte de la JFC (Java Foundation Classes) en la plataforma Java. La JFC provee facilidades para ayudar a la gente a construir GUIs. Swing abarca componentes como botones, tablas, marcos, etc... Las componentes Swing se identifican porque pertenecen al paquete  javax.swing . Swing existe desde la JDK 1.1 (como un agregado). Antes de la existencia de Swing, las interfaces gráficas con el usuario se realizaban a través de AWT (Abstract Window Toolkit), de quien Swing hereda todo el manejo de eventos. Usualmente, para toda componente AWT existe una componente Swing que la reempl...