Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
Cand prea multa modularizare e prea multa?
Last Updated: Aug 29 2022 01:32, Started by
wolfenste
, Aug 25 2022 10:28
·
0
#19
Posted 28 August 2022 - 18:01
Mediul productie, nu este acelasi cu mediul in dev, apoi sunt pachete in plus care le configureaza in cache, Laravel a pregatit totul nu intamplator
este foarte popular. Laravel are optimizari serioase in productie, este poate cel mai popular framework pentru ca reprezinta o firma americana. La una dintre firme am fost obligat sa-l folosesc si este din domeniul bancar, chiar daca ar exista brese de securitate ele ar fi corectate instant, multi pe aici nu stiu ce vorbesc. Laravel face training-uri platite, vrei moca trebuie sa cauti sa pierzi timpul, ei se adreseaza firmelor in special cu training-uri ei reprezinta o entitate, o firma americana. dani.user, on 28 august 2022 - 11:12, said:
Cele mai dese probleme de performanta intalnite de mine in cazul diverselor aplicatii web au avut drept cauza o interactiune ineficienta cu baza de date (interogari prea multe si/sau proaste) nu limbajul in sine. Exemplu detaliat: https://forum.softpe...online-popular/ ORMurile te fac sa uiti ca interactionezi cu un serviciu extern si nu cu niste structuri de date existente deja in memorie. - clasic DB:select(SELECT * From user); etc - Fluent Query Builder: DB:table('user')->get(); - Eloquent: User:all() La firma Eloquent a fost suficient desi pare cel mai lent, uite aici test de performanta: [ https://www.youtube-nocookie.com/embed/3TJfR1Ta4GU?feature=oembed - Pentru incarcare in pagina (embed) Click aici ] Sa vad un test de performanta in C, Rust etc vs Laravel apoi discutam daca diferentele sunt asa mari. Edited by iulian_1976, 28 August 2022 - 18:13. |
#20
Posted 28 August 2022 - 18:09
Interogarea bazei de date returneaza obiecte stdClass
Exista 2 paradigme in materie de ORM 1 Active Record , inspirata din Ruby on Rails, prezenta si in Eloqent/Laravel 2 Entity-Repository, cum e in Doctrine/Sympfony, Hibernate Model-ul din Laravel sau entity-ul din ER au caracteristici distincte De exemplu, un model din Laravel are lifecycle hooks, cum ar fi post-save, post-update De asemenea, un model Laravel are atribute dinamice, stii functiile care incep cu set sau get + atribut name + Attribute :setNameAttribute Un model Laravel are reguli privind diverse "field"-uri, cum ar fi $hidden, $casts etc Plus alte chestii, gen validation, traits Din aceste motive , obiectele stdClass sunt doar niste DTO, si servesc la HIDRAREA obiectelor specifice domeniului |
#21
Posted 28 August 2022 - 18:15
iulian_1976, on 28 august 2022 - 18:01, said:
Mediul productie, nu este acelasi cu mediul in dev, apoi sunt configurari puse in cache, Laravel a pregatit totul nu intamplator este foarte popular. Laravel utiliseaza 3 metode de interograre DB: - clasic DB:select(SELECT * From user); etc - Fluent Query Builder: DB:table('user')->get(); - Eloquent: User:all() La firma Eloquent a fost suficient desi pare cel mai lent, uite aici test de performanta: [ https://www.youtube-nocookie.com/embed/3TJfR1Ta4GU?feature=oembed - Pentru incarcare in pagina (embed) Click aici ] Sa vad un test de performanta in C, Rust etc vs Laravel apoi discutam daca diferentele sunt asa mari. Saptamana trecuta am incarcat 45 milioane de rows intr-o tabela pentru urmatorul an, si incet incet cresc cu acelasi ritm. Ce relevanta au testele alea pe baza de php ? Cam 0 dupa mine. Overhead plus de 60-100 ori peste cat dureaza query-ul spune tot La fel si "select * from table" e demn si reprezinta bine specialistii youtube Edited by radu103, 28 August 2022 - 18:16. |
#22
Posted 28 August 2022 - 18:28
In ce ai incercat? .... in C# Iti dai seama cat inseamna parerea ta pentru Laravel ?
Cand o sa vii cu un test web intre C, C++, Rust, Ruby on Rails etc putem analiza merita, nu merita, vin-o cu ceva concludent. |
#23
Posted 28 August 2022 - 19:02
radu103, on 28 august 2022 - 18:01, said: Pai modularizarea aia prea multa aia topic-ului este ultima problema, prima problema e x30 consum de energie fata de C. Se accepta o gherla de genul x2-x3 (Java, C#) dar peste devine bataie de joc Daca vrem sa fim responsabili cu asta incepem si dupa aia aruncam la gunoi si Laravel pentru gherlele din dotare Curățam mizeriile din PHP nu îl aruncam la gunoi. |
#24
Posted 28 August 2022 - 20:02
asspiration, on 28 august 2022 - 18:09, said:
Interogarea bazei de date returneaza obiecte stdClass Exista 2 paradigme in materie de ORM 1 Active Record , inspirata din Ruby on Rails, prezenta si in Eloqent/Laravel 2 Entity-Repository, cum e in Doctrine/Symfony, Hibernate Model-ul din Laravel sau entity-ul din ER au caracteristici distincte De exemplu, un model din Laravel are lifecycle hooks, cum ar fi post-save, post-update De asemenea, un model Laravel are atribute dinamice, stii functiile care incep cu set sau get + atribut name + Attribute :setNameAttribute Un model Laravel are reguli privind diverse "field"-uri, cum ar fi $hidden, $casts etc Plus alte chestii, gen validation, traits Din aceste motive , obiectele stdClass sunt doar niste DTO, si servesc la HIDRAREA obiectelor specifice domeniului O parte din kernelul Laravel este luat din Symfony, astea sunt deja detalii de finete, ultimul lucreaza in prezent by defaut cu fisiere de configurare Yml si adnotari s-au dus in alta directie. |
#25
Posted 28 August 2022 - 20:25
Facebook o fi fost inceput in PHP, dar cand ajungi la scara lor, si cand ai mii/zeci de mii de dezvoltatori angajati, lucrurile semnificativ diferit. Si daca au acum un layer in PHP care sa randeze HTMLul, nu inseamna ca totul e scris in PHP.
Un benchmark compartiv C(++) vs PHP pentru interogarea bazei de date e usor de scris, dar cu ce folos? Cand ajungi sa ai nevoie de lucrurile delicate oferite C++ ai cam depasit de mult stadiul de "hai sa interogam MySQL pentru orice". Revenind la ORMurile PHP sau din orice alt limbaj versus interogari chioare:
|
#26
Posted 28 August 2022 - 20:37
MarianG, on 28 august 2022 - 19:02, said:
Curățam mizeriile din PHP nu îl aruncam la gunoi. In definitiv Laravel este o firma americana. Deja exista tineri developeri web in firma care nu stiu o linie de SQL, Laravel incurajeaza sa lucrezi cu Eloquent, piata cere mana de lucru ieftina, formata rapid, mana de lucru care sa fie inlocuita rapid. +Avantajele: Laravel ca are multe pachete in spate, gasesti aproape orice raspuns la orice necesitate, asta il face foarte popular. -Dezavantaje: Versiunea majora se schimba in fiecare an, LTS-uri scurte, desi domeniul conex bancar foloseam Laravel 5.5 nu mai primea Security Fixes. dani.user, on 28 august 2022 - 20:25, said:
Facebook o fi fost inceput in PHP, dar cand ajungi la scara lor, si cand ai mii/zeci de mii de dezvoltatori angajati, lucrurile semnificativ diferit. Si daca au acum un layer in PHP care sa randeze HTMLul, nu inseamna ca totul e scris in PHP. Un benchmark compartiv C(++) vs PHP pentru interogarea bazei de date e usor de scris, dar cu ce folos? Cand ajungi sa ai nevoie de lucrurile delicate oferite C++ ai cam depasit de mult stadiul de "hai sa interogam MySQL pentru orice". Revenind la ORMurile PHP sau din orice alt limbaj versus interogari chioare:
Mana de lucru tanara nu stie Sql, cand este nevoie apeleaza la lead... Stai sa vezi Laravel+Vu.js nu stii inca nimic Edited by iulian_1976, 28 August 2022 - 20:49. |
#27
Posted 28 August 2022 - 20:48
Iuliane, nici nu stiam de faza cu Symfony
Ai ramas la faza cu Vue ? Ca intre timp a explodat InertiaJs Si daca vorbim de Inertia, vorbim de Jonathan Reinink Are baiatul asta un curs de optimizare a lucrului cu baze de date in Laravel https://eloquent-course.reinink.ca/ Fix pentru dani |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users