"Nowości" w PHP - czy naprawdę trzeba ich używać?

Hi. Programuję sobie hobbystycznie w PHP. Od czasu do czasu korzystam z jakiejś książki, z jakichś tutoriali itd. Im więcej tego czytam, tym bardziej odnoszę wrażenie, że przy każdej nowości (mam tu na myśli coś, z czego jeszcze nie korzystałem - czyli nowości dla mnie) pada stwierdzenie, że bez tego się nie da pisać, że pisanie tego wymaga itd. Na początku mojej hobbystycznej kariery pisałem jak wszyscy - mieszałem kod HTML z PHP. Później przyszła pora na szablony. Próbowałem kilku ale wybrałem Smarty i dziś już naprawdę nie wyobrażam sobie pisania czegokolwiek bez użycia Smarty. Później przyszła kolej na PDO - nie przekonał mnie ten sposób łączenia z bazami danych i robię to w ten sposób, że do każdej aplikacji stwarzam engine.php a w nim klasę i wszystkie zapytania wykonuję poprzez wywołanie odpowiedniej metody.

Moje główne pytanie brzmi: czy pisanie w taki sposób ma sens czy używanie ORM (Propel, Doctrine) i frameworków (Symfony, Zend) jest naprawdę niezbędne?

Później przyszła kolej na PDO - nie przekonał mnie ten sposób łączenia z bazami danych i robię to w ten sposób, że do każdej aplikacji stwarzam engine.php a w nim klasę i wszystkie zapytania wykonuję poprzez wywołanie odpowiedniej metody.

I bawisz się w klejenie stringów? SQL Injection aż się prosi.

I z PDO zrobisz SQL Injection jak jesteś dupa. Patrz sqli w Drupalu ;]

@neewbie: każdy przechodzi przez etap - "a po co mi to?". strukturalnie też wszystko napiszesz, zgadza się, proste klasy też większość zadowalają. ale jak chcesz pisać większą webaplikację, a nie stronę-wizytówkę z galerią i formularzem kontaktowym, to szybko zauważysz, że wiele mechanizmów faktycznie ma sens - umożliwiają wyeliminowanie powtarzania tego samego kodu i zwiększają rozszerzalność Twojej aplikacji.

abstrakcje, traits, namespace'y - jeszcze parę lat temu powiedziałbym - a po co mi to?

wszystko przyjdzie z doświadczeniem, nic się nie bój ;)

a Symfony, Zend to kobyły, wolę lekkie biblioteki, które są od siebie niezależne i używam tych, których mi pasuje w danym momencie/projekcie.

Dzięki dzek :) A jakie masz zdanie na temat ORM? Lepiej jest tego używać czy nie używać? :)

Nie stosuję relacji w bazach, gdyż sprawia mi to więcej problemów niż pożytku w systemach, które tworzę

ORM fajna sprawa przyśpiesza proces produkcyjny, ale trzeba się przyzwyczaić i dobrze go poznać, bo inaczej będzie więcej kłopotów niż pożytku, sam przez to przechodziłem...

Dlaczego to?
Aby ujednolicić programowanie, abym nie musiał znów przeklinać w wniebogłosy, gdy dostanę jakiś projekt od "niby programisty" , który od nowa tworzył koło.
To wszystko, cała struktura MVC itp, jest tylko po to, by mieć wspólny styl kodowania, wspólny wzorzec, piękność i przejrzystość kodu. Przychodzi nowy programista do firmy, to nie powinien on 2 tygodni spędzać na ogarnianiu gdzie co jest, tylko możliwie jak najszybciej zaczął pisać.

Np. to że masz wszystkie sql w pliku engines.... tam pewnie jest chaos. W dużych projektach ten plik może być nawet megabajtowy. I poczuj to, że tam są zapytania do wszystkich tabel...
A nie lepiej zrobić pliki
Users.php
Posts.php
Settings.php

I trzymać względnie zapytania w innym pliku?

Namespace? A co to, na co to komu, komu to potrzebne?

A z prostej sprawy. Aby programista wiedział co edytuje, gdzie szukać plików odpowiedzialnych za coś. Jak np wejdę w plik z namespacem
\Zend\Db
To już wiem że plik jest odpowiedzialny za połączenie z bazą danych, i wszystkie namespacey dzieci, są klasami pomocniczymi.
I przez to podpowiadanie funkcji/klas stało się bardziej przyjazne użytkownikowi. Bo jeśli szuakm jakiegoś pliku związanego z bazą danych, to wystarczy ze w IDE wpisze new \Zend\Db , to IDE automatycznie mi podpowie wszystkie klasy wewnątrz tego namespace'a

Namespace są tak jakby folderami, pozwalają trzymać ci pliki w porządku, względnie ich działania.

ORM
Co do tego jestem pół na pół. Fajnie mieć ORM, ale tylko dla tabel, którym pasuje ten model. Np. dla tabeli Users. Fajna sprawa.
$user = $tableUsers->get($usr_id);
$user->name = "Lorem";
$tableUsers->save($user);
No i tym prostym kodem zmieniłem sobie imię użytkownika.
A ty byś musiał zrobić specjalnie metodę , gdzie będzie specjalny do tego sql....
A powiedzmy że później będę chciał edytować nazwisko? Ja robię tylko

$user = $tableUsers->get($usr_id);
$user->forename= "Ipsum";
$tableUsers->save($user);

A ty? A ty znów tworzysz metodę, robisz znów sql... itp.

Ale ok, przejdźmy do tworzenia użytkownika.. aby stworzyć użytkownika ja robię

$user = $tableUsers->get($usr_id);
$user->email = "[email protected]",
$user->password = uniqid();
$user->forename ="lorem";
$user->name = "ipsum";
$tableUsers->save($user);

A ty? Ty robisz znów funkcję... z n argumentami pewnie. A w przyszłości np. klient nie bedzie chciał pola "forename"... to ja tylko komentuje kod... a ty wchodzisz do funkcji, usuwasz argument forename, edytujesz sql... w ch!$#$@ roboty.

Jedyne do czego się nie nadaje ORM do widoków. Ja robię czyste sql'e

Też przez to brnąłem, też zrobiłem swego frameworka po swojemu, ale z doświadczeniem poznajesz, że to na prawdę nie jest głupie, wręcz przeciwnie. I później się dowiadujesz, że nic nie znałeś na temat prawdziwego programowania.

Pierwszy post więc witam wszystkich! :)

Co do pytania... Prawda jest taka że im więcej się tworzy tym częściej szuka się drogi na skróty żeby n-ty raz nie robić tego samego, dobry programista to leniwy programista więc koniec konców każdy dochodzi powoli do etapu że 'nie umie żyć' bez jakiegoś rozwiązania/systemu/modułu itp.

ORM to genialna sprawa i to pomijając to, jak bardzo ułatwia korzystanie (w typowy sposób) z bazy danych. Dla mnie główną zaletą ORM jest to, że pozwala uciec od sql, którego po prostu nie da się walidować w trakcie kompilacji. W C#/EF wygląda to tak, że (dla modelu database-first) robisz zmiany w bazie danych, odświeżasz model db, kompilujesz i jeśli gdzieś jest jakiś problem (bo np. pole/view/tabela/sp zostało usunięte lub zmodyfikowane), to przeważnie już na tym etapie to widzisz. I nie wypuścisz babola na produkcję, bo kod się nie kompiluje. Rzecz jasna, nie zawsze tak jest, niemniej jest to spore ułatwienie.
Co prawda jeśli wszystko masz dobrze przykryte testami, to i tak wcześnie wyłapiesz problemy, które wprowadziła Twoja zmiana, jednak nie oszukujmy się, testy to dla wielu programistów czarna magia, a pozostali często olewają to z lenistwa albo braku czasu (bo pracodawca goni). Z tego powodu twierdzę, że używanie ORM pozwala poprawić jakość aplikacji.
A skoro o jakości mowa, to programowanie obiektowe, niejako naturalne dla ORM, poprawia też jakość kodu, bo jest on czytelniejszy. Czytelniejszy, łatwiejszy do pisania kod, rzadsze błędy przyspieszają i uprzyjemniają pracę. Szybsza praca oznacza więcej zarobionych pieniędzy na kwant czasu.

ORM ma też swoje minusy - ogranicza (nie wszystko da się zrobić nie mając dostępu do sql) i spowalnia komunikację aplikacja-baza danych.