Rails 2.xe convenzioni vs. architettura "enterprise"

Naviga le tue risposte
4

Nota: questo è della primavera del 2008, quindi antico in terra di rotaie.

(Il titolo di questo probabilmente non è buono come dovrebbe essere, non riesco a pensarne uno migliore)

Sto per rivisitare un'idea di avvio e la mia piattaforma preferita è Ruby on Rails. Recentemente ho anche iniziato a rileggere il libro "Enterprise Rails" che suggerisce che tu non segui le convenzioni di Rails ma invece separi i tuoi livelli in componenti "fisici" e "logici". Questo è l'unico libro che devo ancora vedere dove viene espressa questa opinione; ogni altro libro di Rails sembra semplicemente seguire il mantra della "convenzione sulla configurazione". In breve, i suggerimenti del libro dividono la tua app / cartella nel seguente:

  • app / models / physical (utilizzato per i file di modello .rb effettivi)
  • app / models / logical (utilizzato per le API dei servizi Web credo)

e fai lo stesso con i tuoi controller e altre aree dell'app. Il libro consiglia inoltre di non utilizzare le migrazioni del database, ma di utilizzare script SQL non elaborati (e in seguito utilizza le viste e le funzioni SQL) in una cartella separata che non rispetta la norma Rails.

La mia domanda è se dovrei preoccuparmi di queste cose se sto appena iniziando a sviluppare la mia applicazione. Ovviamente il libro consiglia di evitare i possibili problemi lungo la strada, e lo sviluppatore .NET in me vuole essere d'accordo, ma lo sviluppatore di Rails in me (ancora un bambino) mi sta dicendo di seguire il "Rails Way" 100% dal momento che sto ancora imparando il framework e il linguaggio Ruby. Mi chiedo quante app di Rails di successo seguano solo la norma con tutti i modelli in app / modelli, tutti i controller in app / controller senza alcuna ulteriore segregazione e quanti fanno un qualche tipo di architettura "enterprise-y"?

    
posta Wayne Molina 11.04.2011 - 15:53
fonte

3 risposte

7

Se stai solo imparando Rails, andrei con il modo Rails ("When in Rome, ..."). Se sei preoccupato che la tua startup possa vacillare a causa di problemi di scalabilità, ti suggerirei di rivisitare la tua decisione di utilizzare RoR. Risolvere i problemi di scalabilità è abbastanza difficile in un ambiente che conosci bene, non devi lottare con uno sconosciuto quando sei sotto la pistola. (Nota che questo non è specifico di Ruby, è applicabile a Python, Scala, Perl, C ++ o qualsiasi altra lingua che non conosci ...)

    
risposta data 11.04.2011 - 17:29
fonte
4

Rail, fortunatamente o meno, non è ancora pronto per le applicazioni aziendali. Un mio amico ha cercato di forzarlo a seguire modelli aziendali e best practice, ma il fatto è che i modelli sono strettamente legati al modello di persistenza. In un'applicazione aziendale "vera", il modello utilizzato dalle viste e dai controller parla con un modello separato denominato modello di dominio. Questo contiene il dominio o la logica aziendale e si connette al livello di persistenza. Poiché Rails non consente questa separazione (so che puoi usare Rack per simulare questo, ma non è banale), non è decisamente un'impresa pronta.

Detto questo, Rails è meravigliosamente adatto per le applicazioni "piccole" (in questa situazione è molto piccola la piccola).

Anche il mio amico ha provato a utilizzare Rails 3 e ha scoperto che ha fatto molti progressi per essere pronto per l'impresa, ma non è ancora arrivato.

    
risposta data 11.04.2011 - 17:30
fonte
1

Immagino cosa intendi per "impresa". Quanti modelli e controller ti aspetti di avere? Ho lavorato su app con circa 30 file di modelli e 10-15 controller senza incorrere in alcun problema, ma immagino che se ne avessi centinaia potrebbe essere un po 'più difficile da gestire.

Ma anche allora, ci sono dei modi per aggirarlo (plugin per esempio).

    
risposta data 11.04.2011 - 17:11
fonte

Leggi altre domande sui tag

Il codice di una storia incompleta dovrebbe essere rimosso dalla compilazione? Strategie per la gestione dell'uso dei tipi in Python