[OT] Chiarimenti su sviluppo three-tier

[CobraArbok]

Premetto, non sono un programmatore.
Ho bisogno di un chiarimento per meglio comprendere un progetto.

Per quello che ho capito, in una architettura three-tier, abbiamo la separazione tra il codice di presentazione, quello di "business" e quello di gestione dei dati.
Da "uomo della strada", nel codice di business ci sono tutte le procedure vere e proprie; esse ricevono i dati dalle maschere di presentazione e le passano al gestore dei DB.
In altre parole, sempre da "uomo della strada":

1. l'utente inserisce i dati in una maschera web
2. I dati vengono "trasferiti" alla logica di business che provvede ad esempio al calcolo dei totali
3. Se deve caricare dei dati, li chiede al gestore del DB
4. Se deve visualizzarli per conferma, ritorna tutto alla maschera
5. Se l'utente preme Invio, la logica di business prende il tutto e lo passa al gestore del DB per il salvataggio del record.

Ora, non essendo un programmatore non ho chiaro il come queste comunicazioni avvengono nel dettaglio, e forse non dovrei neppure conoscerlo.
Quello che mi preme però capire è se questi tre livelli debbano essere effettivamente separati o no.
Perché se io vedo nel codice che visualizza la maschera un qualche cosa che interroga direttamente il DB e mi fa i totali per visualizzarli nel campo accanto, beh, io faccio veramente fatica ad immaginarmi questa come un esempio di programmazione a tre livelli.
A me ricorda più il buon BASIC di una volta, quello nella EPROM del PC. E tanti saluti al three-tier.
O no?

[optime]

La risposta, come sempre, è: dipende. Diciamo che non è obbligatorio separare; in alcuni casi è bene, in altri è uno spreco. In linea generale, più è grande e vasto l'applicativo (e più gente ci lavora), più ha senso.

[CobraArbok]

La risposta, come sempre, è: dipende. Diciamo che non è obbligatorio separare; in alcuni casi è bene, in altri è uno spreco. In linea generale, più è grande e vasto l'applicativo (e più gente ci lavora), più ha senso.

Beh, allora avevo visto giusto.

La faccio breve, si tratta di interfacciare un vecchio applicativo contabile che per varie ragioni non può essere "modernizzato".
La strada che mi sembra più praticabile è una interfaccia Web, autonoma è sé stante, presumibilmente in Python, per realizzare appunto solo le maschere utente.

Andare a scrivere direttamente nel DB, oltre a creare dei potenziali problemi di accesso simultanei, presuppone che dentro l'interfaccia stessa debba andare a mettere la "logica di business".

A questo punto si tratta di pensare ad un qualche meccanismo intelligente, integrato nell'applicativo, per creare il collegamento tra i due.

[alka]

Quello che mi preme però capire è se questi tre livelli debbano essere effettivamente separati o no.

Dal punto di vista del codice, devono essere necessariamente separati, altrimenti non è possibile parlare genericamente di thier.

L'obiettivo di questa architettura, anche se non è indispensabile farlo, è quello di dislocare potenzialmente gli applicativi come servizi anche su diverse macchine. Va da se che, se un thier non comunica con l'altro ma accede direttamente al DB, e quest'ultimo è il compito associato a uno dei thier, possono sorgere dei problemi o comunque l'architettura non rispetta a pieno la separazione richiesta per i suoi livelli (layer).