activerecord come modello, è una buona idea?

Question

Recentemente, grazie alla popolarità dei rail, molte persone hanno cominciato ad usare activerecord come modello.tuttavia, prima di sentire parlare di rail (il mio gruppo di pari non era un fan delle cose open source, ci veniva insegnato in una scuola .NET...) e mentre stavo realizzando il mio progetto dell'ultimo anno, ho trovato questa definizione di modello

Il modello rappresenta i dati aziendali e le regole aziendali che regolano l'accesso e gli aggiornamenti di tali dati.Spesso il modello funge da approssimazione software di un processo del mondo reale, quindi durante la definizione del modello si applicano semplici tecniche di modellazione del mondo reale.

non dice che il modello dovrebbe rappresentare una tabella come fa activerecord.E normalmente all'interno di una transazione, potrebbe essere necessario interrogare alcune tabelle non correlate e quindi manipolare i dati di tabelle diverse...quindi se activerecord viene utilizzato come modello, allora uno dei due dovrebbe stipare tutto il codice logico nel controller (che è piuttosto popolare in alcuni framework php) che rende difficile testare o hackerare il modello activerecord in modo che esegua l'operazione del database su non solo la tabella a cui è mappato, ma anche altre tabelle correlate...

quindi, cosa c'è di così bello nell'abusare di activerecord (IMHO) come modello in un modello architettonico MVC?

Answer 1

Martin Fowler ha descritto questo modello in Patterns of Enterprise Application Architecture insieme ad altri due modelli o architetture.Questi modelli sono adatti a situazioni diverse e a diversi livelli di complessità.

Se vuoi fare solo cose semplici puoi usare Transaction Script.Questa è un'architettura che hai visto in molte vecchie pagine ASP e PHP in cui un singolo script conteneva la logica aziendale, la logica di accesso ai dati e la logica di presentazione.Questo va in pezzi velocemente quando le cose diventano più complicate.

La prossima cosa che puoi fare è aggiungere una certa separazione tra presentazione e modello.Questo è il record attivo.Il modello è ancora legato al database ma hai un po' più di flessibilità perché puoi riutilizzare il tuo modello/accesso ai dati tra visualizzazioni/pagine/qualunque cosa.Non è flessibile come potrebbe essere, ma a seconda della soluzione di accesso ai dati può essere abbastanza flessibile.Framework come CSLA in .Net hanno molti aspetti di questo modello (penso che anche Entity Framework assomigli un po' troppo a questo).Può ancora gestire molta complessità senza diventare irraggiungibile.

Il passaggio successivo è separare il livello di accesso ai dati e il modello.Ciò di solito richiede un buon mappatore OR o molto lavoro.Quindi non tutti vogliono andare in questa direzione.Molte metodologie come la progettazione guidata dal dominio descrivono questo approccio.

Quindi è tutta una questione di contesto.Di cosa hai bisogno e qual è la soluzione migliore.A volte utilizzo ancora lo script di transazione per un semplice codice monouso.

Answer 2

Ho detto molte volte che utilizzare Active Record (o ORM che è quasi la stessa cosa) come modelli di business non è una buona idea.Lasciatemi spiegare:

Il fatto che PHP sia Open Source, gratuito (e tutta quella lunga storia...) gli fornisce una vasta comunità di sviluppatori che riversano codice nei forum, siti come GitHub, codice Google e così via.Potresti vederlo come una cosa positiva, ma a volte tende a non essere "così buono".Ad esempio, supponiamo che tu stia affrontando un progetto e desideri utilizzare un framework ORM per affrontare il tuo problema scritto in PHP, beh...ne avrai molti opzioni tra cui scegliere:

• Dottrina
• Spingere
• QCodo
• Torpore
• Fagiolo rosso

E l'elenco potrebbe continuare all'infinito.Nuovi progetti vengono creati regolarmente.Quindi immagina di aver creato un framework completo e persino un generatore di codice sorgente basato su quel framework.Ma non avete inserito corsi di business perché, dopotutto, "perché scrivere di nuovo gli stessi corsi?".Passa il tempo e viene rilasciato un nuovo framework ORM e vuoi passare al nuovo ORM, ma dovrai modificare quasi tutte le applicazioni client utilizzando il riferimento diretto al tuo modello dati.

In conclusione, Active Record e ORM sono pensati per essere nel livello dati della tua applicazione, se li mescoli con il tuo livello di presentazione, puoi riscontrare problemi come questo esempio che ho appena presentato.

Ascolta le sagge parole di @Mendelt:Leggi Martin Fowler.Ha pubblicato molti libri e articoli sulla progettazione OO e ha pubblicato del buon materiale sull'argomento.Inoltre, potresti voler esaminare Anti-modelli, più specificamente in Blocco del venditore, che è ciò che accade quando rendiamo la nostra applicazione dipendente da strumenti di terze parti.Alla fine ho scritto Questo post sul blog che parla dello stesso problema, quindi se vuoi, dai un'occhiata.

Spero che la mia risposta sia stata di qualche utilità.

Answer 3

Il bello dell'utilizzo di Rails ActiveRecord come modello in MVC è che ti offre un ORM (Object Relational Mapper) automatico e un modo semplice per creare associazioni tra modelli.Come hai sottolineato, a volte MVC può mancare.

Pertanto, per alcune transazioni complesse che coinvolgono molti modelli, suggerirei di utilizzare un Presenter tra il controller e i modelli (Modello presentatore Rails).Il Presenter aggregherebbe i tuoi modelli e la logica transazionale e rimarrebbe facilmente testabile.Sicuramente vuoi sforzarti di mantenere tutta la tua logica aziendale nei tuoi modelli o presentatori e fuori dai tuoi controllori (Controller magro, modello grasso).