En enginyeria de programari, l'arquitectura multinivell (sovint anomenada arquitectura d'n nivells) és una arquitectura client-servidor en què les funcions de presentació, processament d'aplicacions i gestió de dades estan separades físicament. L'ús més estès de l'arquitectura multinivell és l'arquitectura de tres nivells (per exemple, el model d'interconnexió jeràrquica de Cisco).

L'arquitectura d'aplicacions d'N nivells proporciona un model mitjançant el qual els desenvolupadors poden crear aplicacions flexibles i reutilitzables. En segregar una aplicació en nivells, els desenvolupadors adquireixen l'opció de modificar o afegir un nivell específic, en lloc de reelaborar tota l'aplicació. L'arquitectura de N nivells és una bona opció per a aplicacions petites i senzilles per la seva simplicitat i baix cost. A més, pot ser un bon punt de partida quan els requisits arquitectònics encara no estan clars. Una arquitectura de tres nivells normalment es compon d'un nivell de presentació, un nivell lògic i un nivell de dades.

Tot i que els conceptes de capa i nivell sovint s'utilitzen indistintament, un punt de vista força comú és que sí que hi ha una diferència. Aquest punt de vista sosté que una capa és un mecanisme d'estructuració lògica per als elements conceptuals que componen la solució de programari, mentre que un nivell és un mecanisme d'estructuració física per als elements de maquinari que componen la infraestructura del sistema. Per exemple, una solució de tres capes es podria implementar fàcilment en un sol nivell, com en el cas d'una arquitectura extrema centrada en bases de dades anomenada arquitectura només RDBMS o en una estació de treball personal.

Capes El patró arquitectònic de "capes" s'ha descrit en diverses publicacions.

Capes comunes En una arquitectura multicapa lògica per a un sistema d'informació amb un disseny orientat a objectes, les quatre més comunes són les següents:

Capa de presentació (també coneguda com a capa d'IU, capa de vista, nivell de presentació en arquitectura multinivell) Capa d'aplicació (també coneguda com a capa de servei o capa de controlador GRASP) Capa de negoci (també coneguda com a capa de lògica de negoci (BLL), capa de lògica de domini) Capa d'accés a dades (també coneguda com a capa de persistència, registre, xarxa i altres serveis que són necessaris per donar suport a una capa empresarial en particular)

Si l'arquitectura de l'aplicació no té una distinció explícita entre la capa de negoci i la capa de presentació (és a dir, si la capa de presentació es considera part de la capa de negoci), aleshores s'ha implementat un model tradicional client-servidor (de dos nivells).

La convenció més habitual és que la capa d'aplicació (o capa de servei) es considera una subcapa de la capa de negoci, que normalment encapsula la definició de l'API que mostra la funcionalitat empresarial compatible. De fet, les capes d'aplicació/negoci es poden subdividir encara més per emfatitzar subcapes addicionals de responsabilitat diferent. Per exemple, si s'utilitza el patró model-vista-presentador, la subcapa del presentador es podria utilitzar com a capa addicional entre la capa d'interfície d'usuari i la capa de negoci/aplicació (tal com es representa a la subcapa del model).

Alguns també identifiquen una capa separada anomenada capa d'infraestructura empresarial (BI), situada entre la capa o capes de negoci i la capa o capes d'infraestructura. De vegades també s'anomena "capa de negoci de baix nivell" o "capa de serveis empresarials". Aquesta capa és molt general i es pot utilitzar en diversos nivells d'aplicació (per exemple, un CurrencyConverter).

La capa d'infraestructura es pot dividir en diferents nivells (serveis tècnics d'alt nivell o de baix nivell). Els desenvolupadors sovint se centren en les capacitats de persistència (accés a dades) de la capa d'infraestructura i, per tant, només parlen de la capa de persistència o de la capa d'accés a dades (en lloc d'una capa d'infraestructura o una capa de serveis tècnics). En altres paraules, l'altre tipus de serveis tècnics no sempre es considera explícitament com a part de cap capa en particular. La capa d'accés a dades normalment conté un objecte conegut com a Objecte d'accés a dades (DAO).

Cada capa pot existir sense les capes que hi ha a sobre i requereix les capes que hi ha a sota per funcionar. Una altra opinió comuna és que les capes no sempre depenen estrictament només de la capa adjacent que hi ha a sota. Per exemple, en un sistema de capes relaxat (a diferència d'un sistema de capes estricte), una capa també pot dependre de totes les capes que hi ha a sota. El sistema de capes relaxat té més acoblaments i, per tant, és més difícil de canviar. Les arquitectures multinivel poden utilitzar un enfocament híbrid de manera que algunes capes siguin estrictes mentre que altres capes siguin relaxades.

Arquitectura de tres nivells miniatura|400x400px|Visió general d'una aplicació de tres nivells. L'arquitectura de tres nivells és un patró d'arquitectura de programari client-servidor en què la interfície d'usuari (presentació), la lògica del procés funcional ("regles de negoci"), l'emmagatzematge de dades informàtiques i l'accés a les dades es desenvolupen i es mantenen com a mòduls independents, sovint en plataformes separades. Va ser desenvolupada per John J. Donovan a Open Environment Corporation (OEC), una empresa d'eines que va fundar a Cambridge, Massachusetts.

A part dels avantatges habituals del programari modular amb interfícies ben definides, l'arquitectura de tres nivells està pensada per permetre que qualsevol dels tres nivells s'actualitzi o es reemplaci de manera independent en resposta a canvis en els requisits o la tecnologia. Per exemple, un canvi de sistema operatiu al nivell de presentació només afectaria el codi de la interfície d'usuari.

Normalment, la interfície d'usuari s'executa en un PC d'escriptori o una estació de treball i utilitza una interfície gràfica d'usuari estàndard, una lògica de procés funcional que pot consistir en un o més mòduls separats que s'executen en una estació de treball o servidor d'aplicacions, i un RDBMS en un servidor de bases de dades o mainframe que conté la lògica d'emmagatzematge de dades de l'ordinador. El nivell intermedi pot ser de diversos nivells (en aquest cas, l'arquitectura general s'anomena "arquitectura de n nivells").

Nivell de presentació Aquest és el nivell superior de l'aplicació. El nivell de presentació mostra informació relacionada amb serveis com ara la navegació de productes, les compres i el contingut del carretó de la compra. Es comunica amb altres nivells mitjançant els quals publica els resultats al nivell del navegador/client i a tots els altres nivells de la xarxa. En termes senzills, és una capa a la qual els usuaris poden accedir directament (com ara una pàgina web o la GUI d'un sistema operatiu). Nivell d'aplicació (lògica de negoci, nivell lògic o nivell intermedi) El nivell lògic s'extreu del nivell de presentació i, com a capa seva, controla la funcionalitat d'una aplicació mitjançant un processament detallat. Nivell de dades El nivell de dades inclou els mecanismes de persistència de dades (servidors de bases de dades, recursos compartits de fitxers, etc.) i la capa d'accés a dades que encapsula els mecanismes de persistència i exposa les dades. La capa d'accés a dades hauria de proporcionar una API al nivell d'aplicació que exposi mètodes per gestionar les dades emmagatzemades sense exposar ni crear dependències dels mecanismes d'emmagatzematge de dades. Evitar les dependències dels mecanismes d'emmagatzematge permet actualitzacions o canvis sense que els clients del nivell d'aplicació es vegin afectats o ni tan sols siguin conscients del canvi. Igual que amb la separació de qualsevol nivell, hi ha costos d'implementació i sovint costos de rendiment a canvi d'una millora de l'escalabilitat i la mantenibilitat.

Referències

Categoria:Programari