Czy istnieje przypadek użycia singletonów z dostępem do bazy danych w PHP?

Singletony mają bardzo mało - jeśli nie powiedzieć-użycia w PHP.

W językach, w których obiekty żyją w pamięci współdzielonej, Singletony mogą być używane do utrzymania niskiego zużycia pamięci. Zamiast tworzyć dwa obiekty, odwołuje się do istniejącej instancji ze współdzielonej globalnie pamięci aplikacji. W PHP nie ma takiej pamięci aplikacji. Singleton utworzony w jednym żądaniu żyje dokładnie dla tego żądania. Singleton utworzony w innym żądaniu wykonanym w tym samym czasie jest wciąż zupełnie innym przykład. Tak więc jeden z dwóch głównych celów Singletonu nie ma tutaj zastosowania.

Ponadto wiele obiektów, które mogą istnieć koncepcyjnie tylko raz w Twojej aplikacji, niekoniecznie wymaga mechanizmu językowego, aby to wymusić. Jeśli potrzebujesz tylko jednej instancji, to nie tworzysz kolejnej . Tylko wtedy, gdy może nie mieć innej instancji, np. gdy kittens umiera podczas tworzenia drugiej instancji, możesz mieć poprawny przypadek użycia dla Singleton.

Innym celem byłoby posiadanie globalnego punktu dostępu do instancji w ramach tego samego żądania. Chociaż może to brzmieć pożądane, to tak naprawdę nie jest, ponieważ tworzy sprzężenie z globalnym zakresem (jak wszelkie globale i statyki). to sprawia, że testowanie jednostkowe jest trudniejsze , a Twoja aplikacja jest ogólnie mniej łatwa do utrzymania. Istnieją sposoby, aby to złagodzić, ale ogólnie rzecz biorąc, jeśli chcesz mieć tę samą instancję w wielu klasach, użyj Dependency Injection .

Zobacz moje slajdy dla singletonów w PHP-dlaczego są złe i jak można je wyeliminować ze swoich aplikacji dla dodatkowych informacji.

Nawet Erich Gamma , jeden z wynalazców wzoru Singletona, wątpi w ten wzór obecnie:

"jestem za porzuceniem Singletona. Jego zastosowanie jest prawie zawsze zapachem designu"

Czytaj dalej

• Jak jest testowanie wzorca rejestru lub singleton trudne w PHP?
• jakie są wady używania klasy bazy danych PHP jako singleton?
• projektowanie klas abstrakcji baz danych przy użyciu PHP PDO
• czy singleton będzie dobrym wzorem dla strony mikroblogowej?
• modyfikowanie klasy do enkapsulacji zamiast dziedziczenia
• Jak uzyskać dostęp do obiektu z innej klasy?
• dlaczego Singletony nie mają zastosowania w PHP
• Czysty Kod Rozmowy-Singletony i Państwo Globalne

Jeśli po powyższym, nadal potrzebujesz pomocy w podjęciu decyzji:

Kto potrzebuje singletonów w PHP?

Zauważ, że prawie wszystkie zastrzeżenia do singletonów pochodzą z technicznych punktów widzenia - ale są one również bardzo ograniczone w swoim zakresie. Szczególnie dla PHP. Najpierw wymienię niektóre powody używania singletonów, a następnie przeanalizuję zastrzeżenia dotyczące używania singletonów. Po pierwsze ludzie, którzy ich potrzebują:

- osoby, które kodują duży framework/codebase, który będzie używany w wielu różnych środowiskach, będą musiały pracuj z istniejącymi wcześniej, różnymi frameworkami / bazami kodowymi, z koniecznością implementacji wielu różnych, zmieniających się, nawet kapryśnych żądań od klientów/szefów/kierownictwa / liderów jednostek.

Zobacz, wzór Singletona jest samowystarczalny. Po zakończeniu, Klasa singleton jest sztywna w każdym kodzie, w którym ją umieścisz, i działa dokładnie tak, jak utworzyłeś jej metody i zmienne. I jest to zawsze ten sam obiekt w danym zapytaniu. Ponieważ nie można go utworzyć dwa razy, aby być dwoma różne obiekty, wiesz czym jest obiekt singleton w danym punkcie kodu - nawet jeśli singleton jest wstawiany do dwóch, trzech różnych, starych, nawet spaghetti codebases. W związku z tym ułatwia to pod względem celów rozwojowych-nawet jeśli w tym projekcie pracuje Wiele osób, Kiedy widzisz, że singleton jest inicjowany w jednym punkcie w danym kodzie, wiesz, co to jest, co robi, jak robi i w jakim jest stanie. Gdyby to była tradycyjna Klasa, musiałbyś śledź, gdzie został utworzony ten obiekt po raz pierwszy, jakie metody były w nim wywoływane do tego momentu w kodzie i jego konkretny stan. Ale wrzuć tam singleton, a jeśli upuścisz odpowiednie metody debugowania, informacji i śledzenia Singletona podczas kodowania, wiesz dokładnie, co to jest. Dlatego ułatwia to pracę z różnymi bazami kodowymi, z koniecznością integracji kodu, który został zrobiony wcześniej z różnymi filozofiami lub zrobiony przez ludzie, z którymi nie masz kontaktu. (czyli sprzedawca-projekt-firma-cokolwiek już nie ma, nie ma wsparcia nic).

- osoby, które muszą pracować z zewnętrznymi API , usługami i stronami internetowymi.

Jeśli przyjrzysz się bliżej, nie różni się to zbytnio od poprzedniego przypadku-interfejsy API, usługi, strony internetowe innych firm są jak zewnętrzne, izolowane bazy kodowe, nad którymi nie masz kontroli. Wszystko może się zdarzyć. Dzięki singleton session / user class możesz zarządzać dowolną rodzaj implementacji sesji / autoryzacji od zewnętrznych dostawców, takich jak OpenID, Facebook, Twitter i wiele innych - i możesz zrobić to wszystko w tym samym czasie z tego samego obiektu singleton-który jest łatwo dostępny, w znanym stanie w dowolnym momencie w dowolnym kodzie, do którego go podłączysz. Możesz nawet tworzyć wiele sesji dla wielu różnych interfejsów API/usług innych firm dla tego samego Użytkownika w swojej witrynie internetowej/aplikacji i robić to, co chcesz z nimi.

Oczywiście, wszystko to może być również tonowane tradycyjnymi metodami przy użyciu normalnych klas i obiektów - haczyk jest tutaj, singleton jest bardziej uporządkowany, schludniejszy i dlatego z tego powodu łatwiejsze do zarządzania/testowania w porównaniu do tradycyjnego użycia klasy / obiektu w takich sytuacjach.

- ludzie, którzy potrzebują szybkiego rozwoju

Globalne zachowanie singletonów ułatwia budowanie dowolnego kodu z frameworkiem, który ma zbiór singletony do zbudowania, ponieważ gdy dobrze zbudujesz swoje klasy Singletona, ustalone, dojrzałe i ustawione metody będą łatwo dostępne i użyteczne w dowolnym miejscu, w dowolnym czasie, w spójny sposób. Dojrzewanie klas zajmuje trochę czasu, ale potem są solidne, spójne i użyteczne. Możesz mieć tyle metod w singletonie, co chcesz, i choć może to zwiększyć ślad pamięci obiektu, przynosi znacznie więcej oszczędności w czasie wymaganym do szybkiego development-metoda, której nie używasz w jednej instancji aplikacji, może być użyta w innej zintegrowanej, a możesz po prostu dodać nową funkcję, o którą klient/szef/kierownik projektu prosi tylko o kilka modyfikacji.

rozumiesz. Teraz przejdźmy do zastrzeżeń do singletonów i the unholy crusade against something that is useful:

- głównym zarzutem jest to, że utrudnia to testowanie.

I naprawdę, to ma do niektórych zakres, nawet jeśli można go łatwo złagodzić, podejmując odpowiednie środki ostrożności i kodując procedury debugowania w singletonach ze świadomością, że będziesz debugować singleton. Ale widzisz, nie różni się to zbytnio od jakiejkolwiek innej filozofii/metody/wzorca kodowania, która istnieje - po prostu singletony są stosunkowo nowe i mało rozpowszechnione, więc obecne metody testowania kończą się porównywalnie niekompatybilnymi z nimi. Nie różni się to jednak w żadnym aspekcie języków programowania - różne style wymagają różnych podejść.

Jeden punkt ten zarzut jest płaski w tym, że ignoruje fakt, że aplikacje opracowane nie są do "testowania", a testowanie nie jest jedynym etapem / procesem, który przechodzi w rozwój aplikacji. Aplikacje są opracowywane do użytku produkcyjnego. I jak wyjaśniłem w sekcji "who needs singletons", singletony mogą wyciąć wiele ze złożoności konieczności pracy kodu z wieloma różnymi bazy kodów / aplikacje/usługi stron trzecich. Czas, który może zostać utracony podczas testowania, to czas uzyskany podczas opracowywania i wdrażania. Facebook OpenID, Twitter, OpenID, wiele innych i kto wie, co będzie dalej, jest szczególnie przydatne w dobie uwierzytelniania/aplikacji/integracji innych firm .

Choć jest to zrozumiałe-programiści pracują w bardzo różnych okolicznościach w zależności od swojej kariery. Oraz dla osób pracujących w stosunkowo dużych firmach o zdefiniowanych działach różne, zdefiniowane oprogramowanie / aplikacje w wygodny sposób i bez nadchodzącej zagłady cięć/zwolnień budżetowych i towarzyszącej im potrzeby robienia wielu rzeczy z wieloma różnymi rzeczami w tani / szybki/niezawodny sposób, singletony mogą nie wydawać się tak konieczne. I może to być nawet uciążliwe / przeszkodą do tego, co już mają.

Ale dla tych, którzy muszą pracować w brudnych okopach "zwinnego" rozwoju, mając do realizacji wiele różnych żądań (czasem nierozsądnych) od ich klient/kierownik/projekt, singletony są ratunkiem z powodów wyjaśnionych wcześniej.

- innym sprzeciwem jest to, że jego ślad pamięci jest wyższy

Ponieważ nowy singleton będzie istniał dla każdego żądania od każdego klienta, może to być sprzeciw dla PHP. W przypadku źle skonstruowanych i używanych singletonów, ślad pamięci aplikacji może być wyższy, jeśli wielu użytkowników jest obsługiwanych przez aplikację w danym momencie.

Chociaż jest to ważne dla każdego rodzaju podejścia można podjąć podczas kodowania rzeczy. Pytania, które należy zadać, są, metody, dane, które są przechowywane i przetwarzane przez te singletony niepotrzebne? Ponieważ, jeśli są one niezbędne w wielu żądaniach, które aplikacja otrzymuje, to nawet jeśli nie używasz singletonów, te metody i dane będą obecne w Twojej aplikacji w jakiejś formie lub innej poprzez kod. Więc wszystko staje się pytaniem, ile pamięci będziesz oszczędzać, kiedy zainicjujesz tradycyjną klasę obiekt 1/3 do przetwarzania kodu i zniszczyć go 3/4 do niego.

Widzisz, gdy tak to ujmiesz, pytanie staje się zupełnie nieistotne - nie powinno być zbędnych metod, danych przechowywanych w obiektach w kodzie - niezależnie od tego, czy używasz singletonów, czy nie. Tak więc ten sprzeciw wobec singletonów staje się naprawdę zabawny, ponieważ zakłada, że będą niepotrzebne metody, dane w obiektach utworzonych z klas, których używasz.

- niektóre nieprawidłowe zastrzeżenia, takie jak " czyni utrzymanie wielu połączeń w bazie danych niemożliwe/trudniejsze '

Nie mogę nawet zacząć rozumieć tego sprzeciwu, kiedy wszystko, co trzeba utrzymać wiele połączeń z bazą danych, wiele selekcji bazy danych, wiele zapytań do bazy danych, wiele zestawów wyników w danym singletonie, to utrzymywanie ich w zmiennych/tablicach w singletonie tak długo, jak są potrzebne. Może to być tak proste, jak trzymanie ich w tablicach, ale możesz wymyślić dowolną metodę, której chcesz użyć, aby to osiągnąć. Ale zbadajmy najprostszy przypadek, użycie zmiennych i tablic w danym singletonie:

Wyobraź sobie, że poniżej znajduje się wewnątrz danej bazy singleton:

$this - > connections = array(); (błędna składnia, po prostu wpisałem ją tak, aby dać ci obrazek-właściwą deklaracją zmiennej jest public $connections = array (); a jej użycie to $this->connections['connectionkey'] naturalnie)

Możesz skonfigurować i zachować wiele połączeń w dowolnym czas w tablicy w ten sposób. To samo dotyczy zapytań, zestawów wyników i tak dalej.

$this - >query (QUERYSTRING, 'queryname',$this - >connections ['particulrconnection']);

Który może po prostu wykonać zapytanie do wybranej bazy danych z wybranym połączeniem i po prostu zapisać w swoim

$this - > results

Tablica z kluczem 'queryname'. Oczywiście musisz mieć kodowaną metodę zapytań - co jest trywialne.

To umożliwia możesz utrzymać praktycznie nieskończoną liczbę (o ile limity zasobów pozwalają oczywiście) różnych połączeń baz danych i zestawów wyników, o ile ich potrzebujesz. I są one dostępne dla dowolnego fragmentu kodu w dowolnym punkcie w dowolnej bazie kodu, do której ta klasa singleton została utworzona.

Oczywiście, naturalnie musisz uwolnić zestawy wyników i połączenia, gdy nie są potrzebne - ale to oczywiste, i nie jest to specyficzne dla singletonów lub innych metoda/styl/koncepcja kodowania.

W tym momencie możesz zobaczyć, jak możesz utrzymywać wiele połączeń / stanów do aplikacji lub usług innych firm w tym samym singletonie. Nie aż tak.

W skrócie, w końcu, singleton patterns są tylko kolejną metodą / stylem / filozofią do programowania, i są tak przydatne, jak każda inna, gdy są używane we właściwym miejscu, we właściwy sposób. Co nie różni się od niczego.

Zauważysz, że w większości w artykułach, w których singletony są rozbijane, zobaczysz także odniesienia do "globali" jako "zła".

Spójrzmy prawdzie w oczy-wszystko, co nie jest właściwie używane, nadużywane, nadużywane, jest złe. Nie ogranicza się to do żadnego języka, żadnej koncepcji kodowania, żadnej metody. Za każdym razem, gdy widzisz kogoś wydającego ogólne Oświadczenia typu "X is evil", uciekaj od tego artykułu. Szanse są bardzo duże, że jest to produkt ograniczonego punktu widzenia - nawet jeśli punkt widzenia jest wynikiem wieloletniego doświadczenia w czymś szczegĂłlnoĹ "Ä ‡ - ktĂłra na ogĂłĹ' Ko koĹ " czy siÄ ™ wynikiem zbyt duĹźej pracy w danym stylu/metodzie - typowy konserwatyzm intelektualny.

Niekończące się przykłady mogą być podane na to, począwszy od "globals are evil" do "iframes are evil". Jeszcze około 10 lat temu, nawet proponowanie użycia iframe w dowolnej aplikacji było herezją. Potem pojawia się Facebook, wszędzie iframes i zobacz, co się stało-iframes nie są już takie złe.

Są jeszcze ludzie, którzy uparcie nalegaj, że są " źli " - i czasami też z dobrego powodu - ale, jak widzisz, istnieje potrzeba, jeśli ramki wypełniają tę potrzebę i działają dobrze, a zatem cały świat po prostu idzie dalej.

Głównym atutem programisty/kodera/inżyniera oprogramowania jest wolny, otwarty i elastyczny umysł.

Singletony są uważane przez wielu za Anty-wzorce , ponieważ są tak naprawdę tylko gloryfikowanymi zmiennymi globalnymi. W praktyce jest stosunkowo niewiele scenariuszy, w których jest konieczne , Aby klasa miała tylko jedną instancję; zwykle jest tak, że jedna instancja jest wystarczająca , w którym to przypadku implementacja jej jako Singletona jest całkowicie niepotrzebna.

Odpowiadając na pytanie, masz rację, że singletony to przesada. Wystarczy prosta zmienna lub funkcja. A jednak lepszym (bardziej solidnym) podejściem byłoby użycie dependency injection w celu całkowitego wyeliminowania potrzeby stosowania zmiennych globalnych.

W twoim przykładzie masz do czynienia z pojedynczym kawałkiem pozornie niezmiennej informacji. W tym przykładzie Singleton byłby przesadą i samo użycie statycznej funkcji w klasie wystarczy.

Więcej myśli: być może doświadczasz przypadku wdrażania wzorców dla wzorców i twoje przeczucie mówi Ci "nie, nie musisz" z powodów, które napisałeś.

Ale: nie mamy pojęcia o wielkości i zakresie twojego projektu. Jeśli jest to proste kod, być może wyrzucić, że nie jest prawdopodobne, aby trzeba było zmienić następnie tak, śmiało i używać statycznych członków. Ale jeśli uważasz, że twój projekt może wymagać skalowania lub być przygotowany do kodowania konserwacji w dół drogi, to tak, możesz użyć wzoru Singletona.

Po pierwsze, chcę tylko powiedzieć, że nie znajduję zbyt wielu zastosowań dla wzoru Singletona. Dlaczego warto trzymać pojedynczy obiekt w całej aplikacji? Zwłaszcza w przypadku baz danych, co zrobić, jeśli chcę połączyć się z innym serwerem bazy danych? Za każdym razem muszę się rozłączyć...? W każdym razie...

Jest kilka wad używania globali w aplikacji (co robi tradycyjne użycie wzoru Singletona):

• trudne do podzielenia test
• Dependency Injection issues
• może tworzyć problemy blokowania (aplikacja wielowątkowa)

Używanie klas statycznych zamiast instancji Singletona daje również pewne te same wady, ponieważ największym problemem Singletona jest metoda static getInstance.

Możesz ograniczyć liczbę instancji klasy bez użycia tradycyjnej metody getInstance:

class Single {

    static private $_instance = false;

    public function __construct() {
        if (self::$_instance)
           throw new RuntimeException('An instance of '.__CLASS__.' already exists');

        self::$_instance = true;
    }

    private function __clone() {
        throw new RuntimeException('Cannot clone a singleton class');
    }

    public function __destruct() {
        self::$_instance = false;
    }

}

$a = new Single;
$b = new Single; // error
$b = clone($a); // error
unset($a);
$b = new Single; // works

Pomoże to w pierwszych punktach wymienionych powyżej: testach jednostkowych i dependency injection; jednocześnie upewniając się, że pojedyncza instancja klasy istnieje w Twojej aplikacji. Na przykład możesz po prostu przekazać wynikowy obiekt do swoich Modeli (wzorzec MVC), aby mogły z nich korzystać.

Zastanów się, czym Twoje rozwiązanie różni się od tego prezentowanego w dokumentach PHP. W rzeczywistości jest tylko jedna "mała" różnica: Twoje rozwiązanie dostarcza wywoływaczom gettera instancję PDO, podczas gdy to w dokumentach dostarcza wywoływaczom {[1] } instancję Database (następnie używają gettera, aby uzyskać instancję PDO).

Więc do jakiego wniosku doszliśmy?

• w kodzie dokumentacji wywołujący otrzymują instancję Database. Klasa Database może ujawniać (w rzeczywistości to powinien ujawnić, jeśli będziesz miał te wszystkie problemy) bogatszy lub wyższy poziom interfejsu niż PDO obiekt, który zawija.
• Jeśli zmienisz implementację na zwracającą inny (bogatszy) Typ niż PDO, wtedy obie implementacje są równoważne. Nie ma żadnych korzyści z podążania za ręczną implementacją.

Jest nadużywane. Początkujący Programiści grok Singleton znacznie łatwiej niż grok innych wzorów. Następnie stosują swoją nowo odkrytą wiedzę wszędzie, nawet jeśli problem pod ręką można rozwiązać lepiej bez Singletona (kiedy trzymasz młotek, wszystko wygląda jak gwóźdź).
• w zależności od języka programowania implementacja Singletona w hermetyczny, nieszczelny sposób może okazać się tytanicznym zadaniem (zwłaszcza jeśli mamy zaawansowane scenariusze: singleton w zależności od innego Singletona, singletony, które mogą być zniszczone i odtworzone, itp.). Po prostu spróbuj poszukać" ostatecznej " implementacji Singletona w C++, Wyzywam cię (posiadam przełomowy nowoczesny projekt C++ Andrei Alexandrescu, który dokumentuje wiele bałaganu).
• nakłada dodatkowe obciążenie zarówno podczas kodowania Singletona, jak i podczas pisania kodu, aby uzyskać do niego dostęp, obciążenie, bez którego możesz się obejść, postępując zgodnie z kilkoma własnymi ograniczeniami dotyczącymi tego, co próbujesz zrobić ze zmiennymi programu.

Tak więc, jako finał wniosek: Twój singleton jest w porządku. Nie używanie Singletona w ogóle jest w porządku przez większość czasu, jak również.

Twoja interpretacja jest poprawna. Singletony mają swoje miejsce, ale są nadużywane. Często dostęp do statycznych funkcji członowych jest wystarczający (zwłaszcza, gdy nie trzeba w żaden sposób kontrolować czasu budowy). Lepiej, możesz po prostu umieścić kilka darmowych funkcji i zmiennych w przestrzeni nazw.

Podczas programowania nie ma "dobra " i" zła"; jest "dobra praktyka" i "zła praktyka".

Singletony są zazwyczaj tworzone jako klasa, która zostanie później ponownie użyta. Muszą być tworzone w taki sposób, aby programista nie przypadkowo stworzył dwóch instancji podczas kodowania o północy.

Jeśli masz prostą małą klasę, która nie powinna być tworzona instancyjnie więcej niż raz, nie potrzebujesz , aby zrobić z niej singleton. To tylko siatka bezpieczeństwa, jeśli masz.

To nie jest zawsze zła praktyka posiadania obiektów globalnych. Jeśli wiesz, że będziesz go używać globalnie/wszędzie/przez cały czas, może to być jeden z niewielu WYJĄTKÓW. Jednak globale są ogólnie uważane za "złe praktyki" w taki sam sposób, jak goto jest uważany za złe praktyki.

Nie widzę w tym żadnego sensu. Jeśli zaimplementowałeś klasę w taki sposób, że łańcuch połączeń został pobrany jako parametr do konstruktora i utrzymał listę obiektów PDO (po jednym dla każdego unikalnego łańcucha połączeń), to być może byłoby jakaś korzyść, ale implementacja Singletona w tej instancji wydaje się bezsensownym ćwiczeniem.

Nic Ci nie umyka, z tego co widzę. Przykład jest dość wadliwy. Robiłoby to różnicę, gdyby Klasa singleton miała jakieś niestatyczne zmienne instancji.