Forum PHP.pl

...to wygoogluje jak to zrobić, i zrobi. Nie dramatyzuj.

Nie ma nic gorszego, niż taki "programista", który potrafi zainstalować i skonfigurować oddzielnie apache, php i mysql, ale programować nie potrafi...

Często przytaczany jest taki argument, że ORM daje warstwę abstrakcji nad używaną bazą danych i pozwala ją zmienić. To prawda, ale nie cała. W realnych aplikacjach, szczególnie tych złożonych, praktycznie nigdy nie zachodzi proces wymiany silnika bazodanowego. Jest to zwyczajnie teoretyczny, akademicki profit z korzystania z ORM, a w praktyce tego się nie robi. W złożonych systemach trzeba w którymś momencie zacząć wykorzystywać "ficzery" charakterystyczne dla używanego silnika bazodanowego. Również naprawdę duże, złożone zapytania do bazy trzeba w końcu pisać ręcznie, przynajmniej częściowo, wykorzystując elementy języka SQL specyficzne dla danej bazy, bo żaden query builder tego tak dobrze za programistę nie zrobi.

Dlatego uważam, że ta możliwość zmiany bazy, to trochę złudzenie, dzięki któremu czujemy się lepiej

A tu kilka innych przemyśleń w tym temacie.

1) Query builder to nie jest ORM. ORM to mapowanie danych przechowywanych w relacyjnej bazie danych, na obiekty wykorzystywane w programowaniu obiektowym. Sposób napisania zapytań do bazy, pobrania wyników i utworzenia z nich obiektów, to jest jedna rzecz, a zwracane obiekty, reprezentujące jakieś dane przechowywane w tejże bazie, to druga. W tej warstwie abstrakcji selecty mogą być tworzone w czystym SQLu, mogą za pomocą builderów, czy jeszcze inaczej - nie jest to ważne, ważne, żeby ta warstwa ORM zwróciła odpowiedni obiekt reprezentujący jakąś logiczną paczkę danych. Według mnie, trzeba te dwie rzeczy odróżniać, choć chyba wszystkie biblioteki ORM dostarczają od razu różnego rodzaju query buildery więc może się wydawać, że query builder to ORM, bo w takich bibliotekach query buildery są zintegrowane z ORMem i czasem nawet nie dają możliwości pobrania czystego SQLa, który został zbudowany (sic!).

2) Wykorzystanie query builderów jest bardzo wygodne, przyśpiesza pracę i znacznie upraszcza kod - tak, ale tylko w przypadku prostych selectów. W przypadku skomplikowanych zapytań, budowanych na podstawie sprawdzania wielu warunków, użycie query builderów równa się napisaniu kodu, który jest później bardzo trudny do zrozumienia i prześledzenia co się dzieje, a programista czytający taki kod w końcu w ogóle nie ma możliwości wydedukować, jak wygląda finalne zapytanie i co robi.

3) Encje jako modele - to jest nieporozumienie. Obiekty zwracane przez ORMy - nazwijmy je tu encjami dla rozróżnienia - nie są tym, co nazywa się modelem dziedzinowym. Te ORMowe encje to potworki, które mają dziesiątki metod i oferują dziesiątki funkcjonalności nie mające nic wspólnego z logiką biznesową reprezentowaną przez model. W takich aplikacjach, nie ma tak naprawdę rozróżnienia między abstrakcyjnym, logicznym modelem reprezentującym logikę biznesową, a tabelą w bazie danych. Te aplikacje stają się z automatu data-centryczne tylko z tego powodu, że programiści używają (wygenerowanych zwykle automatycznie) klas encji ORMowych, mapowanych 1:1 na odpowiednie tabele w bazie, jako modeli dziedzinowych. Na takich ORM-owych modelach-encjach, programista może w dowolnym momencie wykonywać dowolne operacje bazodanowe, co jest może i wygodne, ale bardzo szkodliwe dla całości kodu i projektu. Najgorzej jest, gdy te "encje" to activ-recordy, ale w pozostałych wzorcach jest podobnie. ORM-owe modele to nie są modele w MVC ani tym bardziej w DDD.

4) Z tego samego powodu programiści używający takich encji reprezentujących tabele, zamiast myśleć obiektowo, myślą tak naprawdę w kategoriach tabel z kolumnami danych i zapisu do nich. Jest to absurdalne, że reprezentacja tabeli relacyjnej bazy danych przenika do wyższych warstw, gdzie jest (powinna być) logika biznesowa. Dodatkowo, takie "modele" są trwale związane z używanym frameworkiem (czy ORM-em) ze wszystkimi tego konsekwencjami - przykładowo nie można zmienić klasy bazowej, podlegają jakimś regułom wymuszonym przez konwencję ORMa itd. Pomijam już fakt, że w publicznym interfejsie takich obiektów na 5 metod realizujących rzeczywistą logikę biznesową napisanych przez programistę, jest 50 metod z ORMa...

5) Trzeba pamiętać, że czasem wykorzystywanie ORMa daje ogromny narzut czasowy i pamięciowy dla aplikacji. To potrafi być sporym problemem. Są też inne - patrz tu

Konkludując, warstwa modelu w aplikacji (oprócz tych najprostszych) powinna być zupełnie oddzielona od warstwy składowania danych. Lepiej użyć ORM w warstwie zapisu danych, nie w warstwie logiki aplikacji, gdzie powinny istnieć czyste modele dziedzinowe. Niestety, wszystkie dokumentacje od popularnych frameworków uczą (niejawnie) bardzo złego podejścia, że ORM Model równa się Domain Model. To jest ZŁO

A nie lepiej było użyć usort? Prościej, łatwiej i bez konieczności tworzenia drugiej tablicy pomocniczej...

Słuchaj, przewodnia idea jest taka, że w klasie unikasz bezpośredniego odwoływania się do zmiennych poza klasą, albo pól innych klas (zgroza) Jeśli coś trzeba zrobić związanego z takim polem innej klasy, to być może powinna być do tego odpowiednia metoda w takiej klasie. Jeśli już faktycznie potrzebujesz pobrać wartość takiego pola, to do tego ta klasa, w której jest to pole (nie-publiczne, rzecz jasna) może udostępniać metodę pobierającą (zwyczajowo się na to mówi getter).

Importu nie masz, albo coś jest nie tak z nazwą pliku lub tego extensiona. Sprawdź też wielkość liter.

Oprócz nullowania, unsetowania i używania referencji, możesz też jawnie wywołać czyszczenie pamięci przez gc. Trudno powiedzieć, co Twój kod wyczynia.

hehe trafi się taki temat i od razu człowiekowi wesoło

Można rekurencyjnie, lub po prostu w pętli, z użyciem referencji (dodajesz do istniejącej tablicy parę klucz -> pusta tablica, a w następnej iteracji pętli operujesz na referencji do tego właśnie wstawionego elementu). Inaczej mówiąc, przesuwasz się po doklejanym ogonie listy.

Nie ma innego wyjścia, jak obrabiać sekwencyjnie tą strukturę danych. Wszystko się sprowadza do jakiegoś rodzaju pętli. Jeśli martwisz się tym, że wiele razy jakieś pętle będą iterowały po tej tablicy wyników robiąc za każdym razem co innego, i że będzie to nieoptymalne - to może niepotrzebnie się martwisz? Jeśli jest to jednak faktycznie problem, to rozwiązaniem jest zrobienie wszystkiego w jednej, dużej brzydkiej pętli (ta technika optymalizacyjna ma nawet swoją nazwę, nie pamiętam teraz jaką), ewentualnie pobieranie mniejszej ilości danych (stronicowanie itp.) lub przechowywanie wyników tymczasowych, żeby niepotrzebnie nie iterować itd. No ale takie rozwiązania zaśmiecają kod i są robione tylko w wyjątkowych przypadkach (zwykle mocno naruszają paradygmaty OOP). Czasami może też pomóc zwracanie referencji do utworzonej tablicy (jeśli jest ogromna) i operowanie bezpośrednio na niej, ale generalnie trzeba unikać takiego kombinowania.

Podsumowując, najoptymalniej by było, gdyby robić wszystkie operacje przetwarzające te pobrane z bazy dane w jednej pętli, od razu w momencie ich pobierania, i najlepiej operować na generatorze zwracającym dane z zapytania do bazy, z pominięciem etapu tworzenia w PHP pośredniej tablicy przechowującej pobrane wiersze, ale zdajesz sobie chyba sprawę, że to jest powrót do programowania we wczesnym Basicu...

Spoko rozwiązanie, ale co, jeśli zechcę zapisać maila za pomocą kilku różnych implementacji SaverInterface jednocześnie?

Prościej użyć __DIR__

tu nie chodzi o to, ile można zarobić, tu chodzi o to, czy jesteś "young, passionate and self-motivated person?"

Oprócz tego, o ile dobrze pamiętam, można było utworzyć obiekt klasy Zend_Db_Table i skonfigurować go, po czym używać w zwyczajny sposób do wykonywania operacji na tabeli.

zbychoCom, tak w dużym skrócie, listenery zdarzeń to fragmenty kodu wykonywane po wystąpieniu jakiegoś zdarzenia, zgłaszanego/rzucanego/publikowanego/triggerowanego (itd. bo różnie się na to mówi) gdzieś indziej. W pseudokodzie (i ogromnym uproszczeniu) będzie to coś takiego:

[PHP] pobierz, plaintext 
//mamy jakiś tam event manager, dostępny w jakiś sposób wszędzie
$evm = new EventManager(); 
 
//gdzieś w kodzie coś rejestruje listenera na zdarzenie o nazwie 'user.deleted'
$evm->addListener('user.deleted', function($eventContext){
   //tutaj wykonanie jakiegoś specyficznego kodu z okazji wystąpienia zdarzenia
   //$eventContext dostarcza jakieś dodatkowe info powiązane z tym zdarzeniem, które można wykorzystać:
   echo 'usuniety user ' . $eventContext['user_id'];
});
 
//w innym miejscu kodu jest jakieś wywołanie takiego zdarzenia:
$userRepository->remove($user);
$eventContext = ['user_id' => $user->id];
//ten parametr $eventContext będzie przekazany jako argument wywołania każdego listenera
$evm->triggerEvent('user.deleted', $eventContext); 
[PHP] pobierz, plaintext 

Chodzi o to, że możesz zarejestrować w event managerze wiele listenerów na różne zdarzenia, a po wystąpieniu zdarzenia event manager kolejno wykona kod każdego dołączonego do tego zdarzenia event listenera. Frameworki odpalają różnego rodzaju zdarzenia w pewnych istotnych momentach i w ten sposób możesz się wpiąć ze swoim kodem w takie zdarzenie i coś tam zrobić/zmienić.

a wyświetl dla pewności PHP_INT_SIZE

hehe Pyton_000 mnie ubiegł

-------------------------------------

skoro potrzebujesz różnej logiki, to lepiej napisać więcej krótszych metod. Taki przykład: powiedzmy, że chcesz coś zrobić z otrzymanym argumentem, ale jeśli został przekazany z zewnątrz, to trzeba go najpierw zwalidować, a jeśli z innej wewnętrznej metody klasy to nie trzeba walidować, bo wtedy zawsze jest poprawny. No to tak jakoś to można zrobić:

[PHP] pobierz, plaintext 
class A {
    public function doSomething($value) {
         //najpierw walidacja $value, potem przekaż do metody b() jeśli ok:
         $this->b($value);
    }
 
    private function b($value) {
         //zrób coś z $value, 
    }
 
    private function c() {
        //a to jakaś inna metoda tej klasy, wywołana w jakiś sposób, także używa metody b() 
        //ale nie trzeba robić walidacji argumentu, bo jest zawsze poprawny w tym przypadku
        $value = 'coś tam'; //zawsze poprawne
        $this->b($value);
    }
}
 
class B {
   public function execute() {
       $a = new A();
       //a tu wywołanie "z zewnątrz"
       $a->doSomething('jakiś parametr');
   }
}
[PHP] pobierz, plaintext 

kolega Magan chyba nie chce sterować przepływem kodu w metodzie zależnie od tego, czy została wywołana z innej metody tego obiektu, bądź spoza niego? ^^

Hehe, dobra chłopaki, ubawiłem się tymi komentarzami co do mnie Zamykamy temat.

Sam sobie przeczysz. W PHP namespaców kiedyś nie było, obecnie są. Tak samo jak są języki bez namespaców. Czy można w nich programować? Tak, można. Czy można w PHP programować bez namespaców? Tak, można. Twierdzenie, że nie można, jest zwyczajną bzdurą. Może to być kwestia wyboru, osobistych preferencji programisty, czy będzie pisał swój kod w PHP z użyciem namespaces, czy bez nich, czy to lubi, czy nie lubi. Dziwne mnie jak można tego nie rozumieć.



To samo napisałem wcześniej; nie wiem, czy mi to tłumaczysz, czy powtarzasz to bo się ze mną zgadzasz? Dla uściślenia: moje stanowisko jest tu wyraźnie określone - uważam, że w wielu (głównie małych - ale gdzie granica?) typowych projektach, tzw. przeciętny programista nie potrzebuje przestrzeni nazw, w takim sensie, że nie ma z nich żadnego wymiernego profitu, może poza zaspokojeniem osobistych preferencji i przekonań tegoż programisty.

Kod można świetnie organizować bez użycia przestrzeni nazw, tak samo jest z ładowaniem zależności, autoloadingiem itp. Namespeces tylko pomagają, ułatwiają w niektórych z tych zagadnień. Nie są niezbędne.



Mylisz się - moje stwierdzenie, że trzeba to pisać za każdym razem, nie jest, jak to pogardliwie określiłeś, jęczeniem, ale prostym stwierdzeniem faktu. Pytanie tylko, czy to rozumiesz. Fakt występuje niezależnie od Twojego czy mojego widzimisię. Inną sprawą jest moja czy Twoja subiektywna opinia, tudzież ocena tego faktu, a z opinią jeden się zgadza a drugi nie. Otóż jeśli Ty uważasz, że to jest naturalne, fajne i jak najbardziej w porządku, że na początku pliku znajduje się xx dyrektyw use, i wcale Ci to nie przeszkadza, to OK - nic mi do tego. Mi natomiast to nieco przeszkadza, i traktuję te sekcje use'ów jako swego rodzaju "zło konieczne" istnienia namespaces, bo lepiej tego do tej pory w tych językach nie wymyślono. Z dokładnie tego samego powodu nie lubię także ładowania klas instrukcjami require. Rzecz gustu, można by rzec

Dyskutować to można nad tym czy użycie namespaców, które wiąże się z takimi a takimi kosztami, a daje takie a takie zyski, sumarycznie się opłaca w danym przypadku. No przepraszam, ale dla mnie ktoś, kto pisze wszystko, każdy, nawet najprostszy, jednoplikowy programik PHP zamknięty w namespace, to prawdopodobnie cierpi na nerwicę natręctw bądź robi to bezmyślnie niczym wyuczony nawyk.

Pytanie zadane na początku było: "czy kiedykolwiek potrzebowaliście namespaców?". Niech każdy za siebie odpowie. Ja nie potrzebowałem, choć raz zdarzyło się, że kilka klas w projekcie miało taki sam pierwszy człon nazwy, co pewna zewnętrzna biblioteka której dołączenie było rozważane - ale problem zniknął sam, bo zapadła decyzja użycia innej biblioteki. Więc muszę szczerze przyznać się, że nie nigdy tak naprawdę nie potrzebowałem przestrzeni nazw, choć to nie jest politycznie poprawne

Chciałbym przypomnieć, że póki w PHP nie było przestrzeni nazw, wszyscy programowali bez przestrzeni nazw. Czy więc były potrzebne? Odpowiedź jest oczywiście tylko jedna: NIE - w sensie takim, że nie jest to element języka, którego istnienie miało by określać możliwość napisania programu. To jest proste i logiczne, czego tu można nie rozumieć?

Może problem w tym, że "potrzebować" ma kilka znaczeń. Drugie znaczenie "potrzebowaliście namespaców" jest takie, że chodzi o to, czy programista chciałby mieć możliwość pisania kodu z użyciem namespaców - bo ma taką zachciankę, bo tak jest w innym języku, bo tak jest modnie, bo tak w szkole uczą, albo tak lubi. I w tym sensie faktycznie można przestrzeni nazw "potrzebować" zawsze.

I wreszcie jest trzecie znaczenie "potrzebować namespaców" - gdy ich zastosowanie ulepszy kod, jego organizację i czytelność, itp. - poddajemy coś ocenie i według przyjętych kryteriów stwierdzamy, że tak lub nie. Ale to już wymaga wysiłku umysłowego i faktycznego zrozumienia tematu.

Mogę sobie też wyobrazić, że ktoś "potrzebuje namespaców" do napisania programu, bo bez nich po prostu nie da się tego oprogramowania napisać - no, nie da się zakodować rozwiązania i koniec - nic, zero, bez wyjścia, kaput. Tylko, że... nie widziałem jeszcze takiego przypadku w realu, aczkolwiek chętnie poznam. Mógłby ktoś podesłać link z jakiegoś case study o takim projekcie w PHP?

Niektórzy tu nie mają żadnych argumentów więc co robią? Wydają osądy i używają różnych epitetów pod adresem adwersarzy, co świadczy tylko o tym, że się nie ma żadnego sensownego zdania w temacie - a wiadomo: jak nie wiadomo co powiedzieć, to najłatwiej zmieszać z błotem, zasugerować, że ta druga osoba to albo nowicjusz, albo jakiś staruszek, który "klepie globale", czy inne takie. To naprawdę śmieszne. Paradoksalnie, to przynajmniej pod jednym względem jest dokładnie odwrotnie, bo to właśnie stary wyga będzie miał doświadczenie, dystans i własny osąd (plus zdrowy rozsądek), których to młodziakom czasem brakuje.

Ludzie, o co te kłótnie i święte oburzenie co niektórych strażników jedynie słusznych namespace'ów? Jedni lubią, inni nie lubią te namespace'y. Nie hejtujcie.

Pytanie było: "czy kiedykolwiek, w praktyce, potrzebowaliście namespaców?". Pozwólcie wyrazić każdemu swoje zdanie dlaczego, i tyle. To samo w sobie jest ciekawe. Kiedyś nie potrzebowałem i dało się bez nich programować, żaden projekt nie upadł z powodu braku namespeców Teraz są i zwykle stosuję - ale czy są faktycznie niezbędne? Nie . Więc nie mam ciśnienia na ich stosowanie. Pracuję teraz też przy takim projekcie, w którym nie używamy namespaców, bo taki projekt; od początku w nim namespaces nie było i nie ma. I nie ma z tym żadnego problemu.

Jedni je stosują bo tak się teraz robi i jest to trendy, inni bo mają z tego korzyść i widzą w tym jakąś wartość, a inni nie stosują bo nie potrzebują. Namespaces nie są potrzebne do programowania. Czy są użyteczne? Oczywiście, że tak, ale... w małych, jednorodnych projektach (szczególnie prywatnych) zwykle są zwyczajnie zbędne - ich wprowadzenie nic, ale to kompletnie nic, nie wnosi - nie ma z tego żadnej wartości dodanej do projektu. Co innego jeśli skomplikowanie tworzonego oprogramowania rośnie, lub robi się coś udostępnianego publicznie - obecnie standardem jest wypuścić to we własnej przestrzeni nazw Wiadomo

Wiesz, zgadzam się, że w tak prostym, trywialnym przykładzie, jak ten, który podałeś, łatwiej, lepiej i przyjemniej jest użyć namespace i use. Problem w tym, że w praktyce nie rzadko człowiek trafia na klasy, które mają po 2000+ linii kodu, w których jest 20+ use i jak nie znasz takiego kodu, a musisz go przejrzeć, zrozumieć, nanieść poprawki, to przeglądanie tego jest zwyczajnie utrudnione, bo gdzieś tam w linii 893 $response = new Response() nić Ci nie powie, póki nie skoczysz do use i nie sprawdzisz, co to za Response. Owszem, IDE pomagają, ale:

1) co chwilę trzeba najeżdżać myszką nad nazwę klasy i czytać skąd pochodzi (aż do poznania i zapamiętania kodu);

2) uważam, że trochę głupie jest uzależnianie się od IDE z podpowiedziami, żeby wygodnie przeczytać i zrozumieć kod. Kod powinien być tak napisany, aby można go było łatwo przeczytać i zrozumieć po wydrukowaniu.

I żeby nie było - lubię jednoczłonowe nazwy (w powyższym przykładzie użyłbym aliasa HttpResponse, bo jest bardziej zrozumiały), ale czy jestem zachwycony namespaces w PHP? Nie, to tylko taki ficzer żadna rewelacja. Na dodatek preferuję składnię importu pakietów z kropką jak w Javie, a PHPowe use \d\s\f\g zwyczajnie mi się nie podoba, ale cóż z tego... Jest jak jest, nie ma co narzekać, i tak musimy korzystać z tego, co dostępne

To działa także w drugą stronę. Co za różnica, czy napiszę A\B\C czy A_B_C. Liczba znaków czy czytelność obu jest dokładnie taka sama, a chyba nawet A_B_C jest dla mnie nieco czytelniejsze.



Oczywiście, że nie jest wymagane, ale czym różni się używanie w kodzie tasiemców A_B_C_D od A\B\C\D? Jedynie zamianą znaku "_" na "\".

Namespaces nie są takie złe, mają po prostu swoje wady. Rozwiązują problem kolizji nazw kosztem zwiększenia złożoności kodu.

Zgodzę się z Pilsener, że czasem utrudniają czytanie kodu. Czasem jest to problematyczne by zorientować się i zapamiętać z jakiego namespace pochodzi klasa, szczególnie, gdy jest ich dużo w jednym pliku. Kiedyś pisało się A_B_C i to jednoznacznie i prosto identyfikowało klasę, a teraz używanie samej nazwy C często nie wystarcza, więc trzeba albo skakać do sekcji use i sprawdzać, albo nazywać nazw w stylu A\AB\ABC, albo używać aliasów nawet, jak nie potrzeba, by zwiększyć czytelność: A\B\C as ABC. I faktycznie, nigdy wcześniej nie trafiła mi się kolizja nazw przy nazywaniu A_B_C za to obecnie dość często trafiają się identyczne nazwy klas z użyciem namespace: A\B\C, D\C itp.

Namespaces są całkiem wygodne, gdy używamy ich wewnątrz jakiegoś pakietu/biblioteki - poruszamy się ciągle w tej samej, zamkniętej całości, we wspólnym namespace, używane nazwy są krótsze i pisząc dany fragment oprogramowania autor i tak pamięta całą strukturę plików, wie czego dotyczą używane nazwy, i jego kod jest dla niego czytelny i zrozumiały. Tylko mniej fajne to może potem być dla innego programisty, który używa danej biblioteki.

Poza tym, konieczność pisania instrukcji use na początku klasy przypomina mi includowanie plików poprzez require_once - bardzo tego nie lubię, od czego w końcu jest autoloader? No i przejrzystość kodu czasem siada.

Nawet jak nie ma kolizji nazw końcowych, to po samych tych nazwach klas i interfejsów trudno się czasami zorientować, z jakiego namespace pochodzą, szczególnie gdy jest 30 usów na początku z 10 różnych namespaces...

Ale i tak jesteśmy w najbliższej przyszłości skazani na przestrzenie nazw, więc jak komuś się nie podoba, to pozostaje się przyzwyczaić

a tabela jest InnoDB?

Triggery mogą modyfikować inne tabele, niż ta, na której operacja wywołała trigger, no i oczywiście dane zmienianego wiersza (NEW, OLD). Triggery nie mogą wykonywać operacji zmiany całej "własnej" tabeli. Możesz to obejść pisząc funkcję, która przyjmuje np. id wiersza do skasowania, a wewnątrz ciała funkcji następuje otwarcie transakcji, usunięcie wiersza, update kolumn i zamknięcie transakcji.