Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1

    MVC: chiarimento sul Model

    ciao!
    mi stavo facendo questa domanda sul pattern MVC.
    il controller intercetta l'url, richiama il model e trasmette i dati all view.
    la view serve per rappresentare l'output e formattarlo come vogliamo.
    il model è quello che esegue le operazioni su db.
    giusto?
    quindi in teoria ogni pagina deve avere il proprio controller e la propria view.
    però, se nel model ci vanno le funzioni per database, nn ne basterebbe uno in teoria?
    si mettono la tutte le funzioni per eseguire le operazioni su db e si richiama sempre lo stesso.
    oppure si potrebbe suddivire tra i model con le funzioni più generiche e poi creare dei model con le funzioni più particolari (se ci stanno).
    cioè, non ha molto senso creare un model per ogni pagina....

    ho detto una cretinata??

  2. #2
    tu non devi creare un model per ogni pagina, ma un model per ogni entità del database, quindi tendenzialmente un model per ogni tabella del database. Chiaro che tutti i model estenderanno una classe base che avrà i metodi comuni per l'uso del database, quindi nel 90% dei casi non scriverai codice aggiuntivo, però devi fare più classi non una sola.
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  3. #3
    ok e già così mi hai levato un pò di dubbi.
    però a questo punto ti chiedo: se uno, ad esempio, in un database ha 40 tabelle deve creare 40 model??
    anche così non è proprio comodo.

  4. #4
    Originariamente inviato da fermat
    ok e già così mi hai levato un pò di dubbi.
    però a questo punto ti chiedo: se uno, ad esempio, in un database ha 40 tabelle deve creare 40 model??
    anche così non è proprio comodo.
    si ovvio.... ma su 40 tabelle è probabile che 39 model estenderanno e basta la classe base (quella che ti da tutte le funzioni CRUD) e magari solo uno/due avrà qualche funzione custom.

    Poi non capisco perchè pensi che sia scomodo: 40 tabelle già cominciano ad essere un bel numero da mantenere e sviluppare in codice, pensa se ne cominci ad avere 200...se non dividi bene le logiche e le competenze (sostanzialmente uscendo fuori dal procedurale e facendo un pop decente) ti assicuro che alla fine ti spari sia nel debuggare che nel mantenere cmq il codice che crei.
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  5. #5
    Utente di HTML.it L'avatar di las
    Registrato dal
    Apr 2002
    Messaggi
    1,221
    Originariamente inviato da fermat
    ok e già così mi hai levato un pò di dubbi.
    però a questo punto ti chiedo: se uno, ad esempio, in un database ha 40 tabelle deve creare 40 model??
    anche così non è proprio comodo.
    bè no, 40 tabelle è improbabile che voglia dire 40 oggetti, ad esempio per la gestione delle fatture ti serviranno diverse tabelle (intestazione, righe, causaliSpeda, codiciIva ecc...) tutte queste tabelle le gestisci con un unico oggetto Fatture oppure astraendo ancora di più con un oggetto Documenti che poi verrà esteso dagli oggetti Fatture,NoteDiCredito,Bolle ecc.. ma non è che per ogni tabella devi farti una classe altrimenti salta tutto il concetto di 'OGGETTO'

    Il calcolatore è straordinariamente veloce, accurato e stupido.
    L'uomo è incredibilmente lento, impreciso e creativo.
    L'insieme dei due costituisce una forza incalcolabile.
    (Albert Einstein)

  6. #6
    Originariamente inviato da las
    bè no, 40 tabelle è improbabile che voglia dire 40 oggetti, ad esempio per la gestione delle fatture ti serviranno diverse tabelle (intestazione, righe, causaliSpeda, codiciIva ecc...) tutte queste tabelle le gestisci con un unico oggetto Fatture oppure astraendo ancora di più con un oggetto Documenti che poi verrà esteso dagli oggetti Fatture,NoteDiCredito,Bolle ecc.. ma non è che per ogni tabella devi farti una classe altrimenti salta tutto il concetto di 'OGGETTO'

    dipende dal progetto e da cosa stai modellando (e come)...vabbeh magari non saranno 40, famo 30?20? ma anche se fossero 3, resterebbero cmq 3 classi
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  7. #7
    quindi per fare un esempio pratico.
    ho una tabella clienti con:
    -nome
    -cognome
    -indirizzo
    -telefono

    poi ogni cliente può avere altre sedi separate.
    le sedi sono in un'altra tabella e sono legate al codice cliente.
    quindi io dovrei fare una classepre il cliente, e una per la sede che estende il cliente.
    giusto??

    per le altre tabelle nn trovo collegamenti da esportare in classi.........

  8. #8
    Originariamente inviato da fermat
    quindi per fare un esempio pratico.
    ho una tabella clienti con:
    -nome
    -cognome
    -indirizzo
    -telefono

    poi ogni cliente può avere altre sedi separate.
    le sedi sono in un'altra tabella e sono legate al codice cliente.
    quindi io dovrei fare una classepre il cliente, e una per la sede che estende il cliente.
    giusto??

    per le altre tabelle nn trovo collegamenti da esportare in classi.........

    partiamo dal presupposto che "Sede che estende cliente" non se pò sentì....come fa una Sede (edificio, luogo) ad estendere (quindi ad essere sotto-tipo,figlio,specializzazione) Cliente (persona fisica, organizzazione aziendale,ente giuridico)?
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  9. #9
    Utente di HTML.it L'avatar di las
    Registrato dal
    Apr 2002
    Messaggi
    1,221
    Originariamente inviato da fermat
    quindi per fare un esempio pratico.
    ho una tabella clienti con:
    -nome
    -cognome
    -indirizzo
    -telefono

    poi ogni cliente può avere altre sedi separate.
    le sedi sono in un'altra tabella e sono legate al codice cliente.
    quindi io dovrei fare una classepre il cliente, e una per la sede che estende il cliente.
    giusto??

    per le altre tabelle nn trovo collegamenti da esportare in classi.........
    per me no, io in questo caso farei solo la classe "cliente" che gestisce anche gli indirizzi dei clienti. quindi 2 tabelle 1 classe.

    EDIT: c'era un 'non' di troppo
    Il calcolatore è straordinariamente veloce, accurato e stupido.
    L'uomo è incredibilmente lento, impreciso e creativo.
    L'insieme dei due costituisce una forza incalcolabile.
    (Albert Einstein)

  10. #10
    te lo spiego meglio.
    funziona così qua.
    il cliente (inteso come ragione sociale) ha come minimo un codice (univoco) al quale è associato un indirizzo.
    lo stesso cliente può avere altri codici (sempre univoci), e ad ogni codice corrisponde un altro indirizzo (con altre info tipo email, telefono, ecc.....).
    quindi non mi sembra di aver detto una castroneria così grossa......

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 © 2025 vBulletin Solutions, Inc. All rights reserved.