none
tra orm e db RRS feed

  • Domanda

  • Ciao,

    ho sempre usato sql server come db e gli oggetti di sql (viste,trigger,sp,ufn,tufn ecc...) per gestire la logica del db.

    Oggi mi viene suggerito e vedo dai vari esempi che la logica sta passando sull'applicazione tramite per esempio entity framework e sul db viene lasciato solo le tabelle.

    Quando si sceglie una tecnologia o l'altra? perche? che tipo di analisi dobbiamo fare ?

    grazie,

    Marco Bosco


    Marco Bosco
    mercoledì 27 aprile 2011 17:12

Tutte le risposte

  •  domanda da 1 milione di euro :) .  Se chiedi nel forum di asp.net magari c'è una propensione al lato "software" e a considerare il db come pure e semplici tabelle.

    Tutta la logica viene comandata dallo strato intermedio

    Qui magari qualche perplessità su questo approccio si può evidenziare.

     

    Usare uno strato intermedio ti permette di astrarti molto dal database che eventualmente puoi anche cambiare. Certo ci metti un qualcosa in mezzo che bisogna pur far funzionare in qualche modo.

    Direi che per un sito molto molto articolato e con operazioni semplici (ma in gran quantità) il gioco può valere la candela.

    Rimane il fatto che quando hai qualcosa di complicato o che devi debuggare, hai l'esigenza di vedere cosa arriva direttamente al db sotto forma di query, perchè al dilà di tante filosofie il db risponde solo a comandi sql.

    In sostanza io sono un pò dubbioso su queste nuove tendenze dello strato intermedio. Un sito web ben progettato, ben ordinato, con magari solo per alcuni set di dati (i più usati , i più pesanti dove puoi fare anche politiche di caching) l'utilizzo di un data layer custom possono essere una buona soluzione per molti casi secondo mè.

     

     

     

     

     

    giovedì 28 aprile 2011 07:07
  • Ciao Marco,

    questa è una domanda a cui non è possibile dare una risposta "definitiva", perché la decisione va presa valutando diversi fattori.

    In linea generale direi che l'astrazione dalla base dati è necessaria per progetti di medio/alta complessità; se la tua business logic è scritta in un linguaggio Object Oriented, qualcuno che la "adatti" ad un modello relazionale ci vuole sicuramente, ed è qui che l'ORM entra in gioco.
    Se ti ritrovi a dover scrivere una certa quantità di codice solo per poter "mettere d'accordo" i due mondi, probabilmente stai scrivendo un mini-ORM, quindi tanto vale usarne uno già pronto (e già testato :-)); e pensa che il cliente ti chiede di implementare una business logic, non un prodotto che persiste le informazioni sul database... :-)

    Qualsiasi ORM "serio" permette un tuning preciso dell'SQL generato, quindi non porrei il discorso in soli termini di performance. Conta che un ORM di solito ti dà out-of-the-box:

    1. Astrazione dal DB engine (il codice, *in teoria*, funziona, ad esempio, sia su SQL Server che su Oracle, che su DB2 semplicemente cambiando una connection string e poco altro).
    2. Sistemi di caching piuttosto evoluti.
    3. Ottimizzazione dell'SQL generato in modo da agire sui soli campi/tabelle necessarie e possibilità di tuning del fetch plan.

    e tanto altro, ma soprattutto, la possibilità pensare alla tua applicazione in termini di "oggetti" e non di "tabelle"/"viste".

    Chiaro che gestire un ORM può non essere semplice al primo impatto, quindi è una cosa che va valutata insieme ai requisiti e alla complessità del progetto.

    HTH

     


    Alberto Dallagiacoma
    My Blog: http://blogs.ugidotnet.org/alby
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org
    martedì 3 maggio 2011 13:24