Chiarimenti su architetture software 3-tier e MVC

di il
4 risposte

Chiarimenti su architetture software 3-tier e MVC

Salve a tutti,
sono nuovo di questo forum.
Mi sto avvicinando ora al mondo dell'ingegneria del software e ho qualche dubbio che mi attanaglia.
Ho dato uno sguardo a tutti i pattern architetturali e a quelli di disegno, questi ultimi teorizzati dalla GoF.
Il primo più grosso dubbio riguarda più che altro i pattern architetturali,in particolare mi chiedevo se il pattern "Layers" cher rientra nella macrocategoria "From mud to structure" corrisponda di fatto a quello che viene comunemente conosciuto come n-tier e nella sua accezzione ancora più comune nel caso specifico il 3-tier.
Altro dubbio è la differenza tra il pattern "MVC" che dovrebbe far parte della macrocategoria "Interactive system" ed il pattern 3-tier.
Apparentemente sembrano uguali ma mi sfugge qualcosa.
Vi ringrazio anticipatamente per il supporto.

Luca

4 Risposte

  • Re: Chiarimenti su architetture software 3-tier e MVC

    Ti rispondo subito: antani.
    E' il classico "blablabla" che viene spacciato nei corsi di ingegneria del software (già ingegneria del software per quanto mi riguarda è un non senso, ma vabbè oggi se non sei ingegnere di qualcosa o non progetti un qualcos'altro tipo un tortellino non sei nessuno).

    Nel 99% dei casi (anzi 99.99999) non si tratta che di un tentativo di "formalizzazione ex-post" di quello che si è fatto per anni, per necessità.

    Ad esempio 3 tier non è nulla più che un browser, un server, e un database (... ci vogliono davvero studi molto approfonditi di ingegneria del tortellino per suddividere così un'applicazione web!)

    MVC invece è il "cugino" ad oggetti, dove "qualcosa" (i dati) vengono modificati attraverso un "qualcosa" (oggetto misterioso) per poi essere mostrati (sempre mediante un oggetto magico)

    Più nel concreto? Cosa ti turba?
  • Re: Chiarimenti su architetture software 3-tier e MVC

    Innanzitutto ti ringrazio per la risposta!
    Rispondo punto per punto.

    +m+ ha scritto:


    Ad esempio 3 tier non è nulla più che un browser, un server, e un database (... ci vogliono davvero studi molto approfonditi di ingegneria del tortellino per suddividere così un'applicazione web!)
    Quindi sostanzialmente mi stai dicendo che 3-tier è più un qualcosa inerente la distribuzione "fisica" dei vari strati anche su macchine/server diversi.Confermi?

    +m+ ha scritto:


    MVC invece è il "cugino" ad oggetti, dove "qualcosa" (i dati) vengono modificati attraverso un "qualcosa" (oggetto misterioso) per poi essere mostrati (sempre mediante un oggetto magico)
    Perdonami ma non mi è chiaro che intendi per "cugino". L'MVC è una implementazione particolare di 3-tier o sono due cose diverse? Sta cosa che ogni componente del MVC ha compito simile al tier del 3-tier mi inganna temo

    +m+ ha scritto:


    Più nel concreto? Cosa ti turba?
    Guarda la cosa che più in assoluto mi turba è capire nel progetto dove sono stato allocato al momento, quale è l'architettura software utilizzata.
    La solution del progetto asp .net è composta da 3 progetti DAL,BAL e Presentation (asp .net) di fatto il deploy avviene in una sola macchina server, mentre il DB risiede su altro server... ma quindi sarebbe un 3-tier che però sfrutta la distribuzione possibile solo parzialmente?
  • Re: Chiarimenti su architetture software 3-tier e MVC

    lukecodewalker ha scritto:


    Quindi sostanzialmente mi stai dicendo che 3-tier è più un qualcosa inerente la distribuzione "fisica" dei vari strati anche su macchine/server diversi.Confermi?
    Esatto
    Perdonami ma non mi è chiaro che intendi per "cugino". L'MVC è una implementazione particolare di 3-tier o sono due cose diverse? Sta cosa che ogni componente del MVC ha compito simile al tier del 3-tier mi inganna temo
    E' un pattern nato per "oggettizzare" i programmi, con una logica analoga (vagamente) a 3 tier.
    Nel primo caso puoi immaginare il classico programmello che gira sul browser del client (1 tier)
    poi avrai il programmello PHP che gira sul server (2 tier)
    e infine avrai il database che girerà da qualche parte (3 tier), spesso sul server 2 ma non è detto

    Se estendi il discorso avrai come pattern un "qualcosa" che
    mostra i dati V (simile vagamente al primo tier)
    esegue i comandi C (simile vagamente al secondo tier)
    memorizza e riprende i dati M (simile vagamente al terzo tier)

    In sostanza si scopre l'acqua calda, poi si conviene che per scaldarla ci vuole un pentolino, e il fuoco, e l'acqua
    O magari un pentolino, un accendino, e l'acqua
    Guarda la cosa che più in assoluto mi turba è capire nel progetto dove sono stato allocato al momento, quale è l'architettura software utilizzata.
    La solution del progetto asp .net è composta da 3 progetti DAL,BAL e Presentation (asp .net) di fatto il deploy avviene in una sola macchina server, mentre il DB risiede su altro server... ma quindi sarebbe un 3-tier che però sfrutta la distribuzione possibile solo parzialmente?
    Mah le "solution" col "deploy" non è che mi siano proprio chiaro.
    La segmentazione dei programmi, ovvero farli funzionare su uno o più server, è solo relativo all'utilizzo di socket TCP. In pratica puoi avere due programmi che colloquiano attraverso sistemi "stretti" (pipe, memoria) oppure laschi (socket).
    Se sono "laschi" te ne freghi se il computer col quale colloqui è pippo.programma.it oppure 127.0.0.1, funziona ugualmente.

    Analogamente puoi avere un programma che funziona su un singolo computer, avendo browser, logica e database sempre nello stesso hardware fisico.
  • Re: Chiarimenti su architetture software 3-tier e MVC

    Diciamo che più che distribuzione fisica, il concetto di N-tier si riferisce ad un architettura client-server in cui si sono N tipi di interlocutori, ognuno dei quali si occupa di certe funzioni. Poi in realtà possono benissimo trovarsi tutti sulla stessa macchina (o due su una macchina e uno su un'altra).

    L'MVC semplicemente ti dice di dividere il tuo programma in 3 componenti che svolgono le funzioni descritte da +m+ e come queste componenti devono dialogare tra loro.

    Il punto importante è che il paradigma MVC può essere mappato su qualsiasi numero di tier (sostanzialmente 1, 2 o 3 tier). Infatti, quello che si fa nell'implementazione classica è mettere nel 3° tier (o primo, dipende dai punti di vista) solo il DBMS server, nel secondo il web server con sopra il grosso dell'applicazione, ovvere Model, Controller e parte del View e nel primo la parte restante del View (che nel caso di applicazioni web è ciò che viene trasferito dal web server al browser). Possibili alternative sono:
    - Costruireil Model direttamente intorno al DBMS, nel terzo tier; Può essere utile se lo stesso Model può essere riciclato da più applicazioni;
    - Usare solo due tier: uno contiene il DBMS ed eventualmente il Model, l'altro è un client "intelligente" che contiene Controller e View ed eventualmente anche Model;
    - Varianti dei tre casi descritti;

    Quanto al progetto che stai seguendo, DAL e BAL potrebbero stare per Data Application Layer e Business Application Layer, per cui credo si tratti di paradigma MVC che segue l'implementazione tipica delle applicazione web.
Devi accedere o registrarti per scrivere nel forum
4 risposte