Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    [OT] Chiarimenti su sviluppo three-tier

    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?
    Ultima modifica di CobraArbok; 13-05-2019 a 14:03

  2. #2
    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.

  3. #3
    Quote Originariamente inviata da optime Visualizza il messaggio
    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.

  4. #4
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    23,819
    Quote Originariamente inviata da CobraArbok Visualizza il messaggio
    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).
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Delphi Succinctly (e-book)

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.