2015-12-23 15 views
7

Sono un programmatore PHP da 12 anni, e praticamente ho reinventato la ruota molte volte, costruendo il mio framework per la nostra web-app closed-source, che viene offerta come soluzione hosted, usando lo stesso database condiviso per tutti i clienti.Laravel senza Eloquent e migrazioni di database?

Ora sto provando Laravel 5 e ho notato che quasi tutti gli esempi utilizzano Eloquent e le migrazioni di database. A me sembra che questo tipo di cose siano mirate a semplici database e persone a cui non piace SQL o database-design (ma potrei sbagliarmi).

Il nostro database MySQL contiene oltre 100 tabelle, un sacco di stored procedure e molti trigger che non riesco a immaginare in un ORM. Utilizziamo Navicat per la progettazione di database e il test delle query SQL. Per aggiornare il database a una versione più recente dell'app, abbiamo già scritto alcuni script e anche strumenti visivi.

Quindi, in pratica, la mia domanda è se Laravel è realmente destinato a essere utilizzato con Eloquent e migrazioni o che mi manca davvero un sacco di funzionalità senza di essi.

Che cosa mi consiglia?

+0

sorry and tia; questo è irrilevante, hai provato il codice con doctrine con mysql db e extjs sull'interfaccia utente? quello potrebbe essere una misura migliore. – unixmiah

+0

dipende da te se non vuoi usare eloquente, ma penso che le migrazioni siano interessanti. – Ceeee

+0

Mai provato Codeigniter, ma mi piacerebbe davvero usare Laravel, dato che al giorno d'oggi sembra il framework più usato. Ora utilizziamo il nostro framework AJAX, ma stiamo pianificando di iniziare ad utilizzare AngularJS o EmberJS. – Dylan

risposta

3

sua fino a voi,

migrazione laravel si rivolge per mantenere versione del database (durante l'utilizzo del controller di versione) anche l'eloquente è rivolto per la semplice mappatura relazione tra le tabelle per le situazioni complesse come multipla Partecipa e tutta la sua non è raccomandato a causa di problema di prestazioni allora si può scegliere Query Builder dà molto meglio le prestazioni, è necessario scrivere query di pianura in laravel utilizzare \DB::statement();

Il laravel è un partner perfetto per angolare Js, più laravel è solo un involucro di pochi componenti belle PHP che è capace di fornire risultati rapidi.

Speranza che aiuta ..

1

L'utilizzo di un ORM semplifica la vita come di scenario più comune è già coperta. Il recupero dei dati, la gestione delle relazioni e il caricamento ansioso/pigro sono un gioco da ragazzi. Ti protegge anche da eventuali vulnerabilità di iniezione che potresti creare durante la scrittura delle tue query codificate. Ovviamente non tutti gli scenari possono essere gestiti da un ORM, quindi la possibilità di scrivere query RAW. Utilizzando laravel di Query Builder si potrebbe fare qualcosa di simile:

$results = DB::select(DB::raw("SELECT * FROM users WHERE username = :username"), ['username' => 'johndoe']);

Se si desidera eseguire le cose come ALTER o SET 's è possibile utilizzare DB::Statement.

Quindi, solo per notare, Eloquent è ORM di laravel mentre il Query Builder è lo strato per costruire le vostre domande in modo sicuro.

Quindi, se utilizzare o meno Eloquente è a voi, credo che hanno fatto un buon lì con un ORM solido, ma sei sempre libero di implementare un altro ORM come dottrina, Data Mapper, ecc Ci sono laravel legami per la maggior parte di quelli.

Edit: Degno di nota è anche che un modello Eloquente fornisce alcuni a portata di mano di extra che semplifica anche le cose, come un JSON convertire __toString, attributi protetti, data casting, ecc Quando il recupero più modelli saranno memorizzati in un Collection, un Arrayable che fornisce ancora più metodi per rendere felici i tempi.Verificalo: http://laravel.com/docs/5.1/eloquent-collections

1

È possibile eseguire query SQL semplici in Laravel se lo si desidera, ma in effetti la maggior parte degli esempi utilizza Eloquent.

Ho fatto un progetto con oltre 100 tabelle e nella maggior parte dei casi è possibile utilizzare Eloquent invece di inserire query SQL raw ogni volta, ma è piuttosto la mia preferenza.

Tuttavia Lei ha detto che avete molti stored procedure e trigger nel database. Per essere onesti, è necessario riconsiderare questo aspetto perché ora si potrebbe inserire molta logica aziendale in Database e la logica è sia nel database che nell'applicazione.

Ho visto un paio di mesi fa questo database in MsSQL ed era orribile - nessuno sapeva davvero cosa stava succedendo e quando volevi migrare questo database su MySQL e l'applicazione Laravel era un grosso problema perché c'era troppa logica in database (non ho preso parte a questo progetto solo a dare un'occhiata)

Problemi correlati