Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Połączenie z bazą danych
Forum PHP.pl > Forum > PHP > Object-oriented programming
Tomplus
Mam pytanie bo mnie nurtuje ostatnio, a nigdzie nie spotkałem jakiejś rzetelnej odpowiedzi, a chodzi mianowicie o korzystanie z połączenia z bazami danych w klasach i nie wiem które rozwiązanie jest lepsze. Poniżej przedstawiłem przykład.

I pytanie który z tych zapisów jest lepszy z perspektywy działania kodu, czy klasaA gdzie wykonuje się połączenie raz a potem udostępnia się obiekt do klas które wymagają takowego połączenia. [używam ten wzorzec]

Czy lepiej wywoływać połączenie za każdym razem gdy wywołujemy daną klasę która wymaga połączenia z bazą?

  1. class db {}
  2.  
  3. class klasaA {
  4. private $db;
  5. public function __construct($db){
  6. $this->db = $db;
  7. }
  8. }
  9.  
  10. class klasaB {
  11. private $db;
  12. public function __construct(){
  13. $this->db = new db;
  14. }
  15. }
viking
Połączenie z BD jest zazwyczaj kosztowną operacją. Tworzenie nowego dla każdej klasy nie ma żadnego logicznego sensu. Przykład A to często używany DI.
Damonsson
Jeżeli potrzebujesz innego obiektu to dołączasz go przez DI, czyli wersja A. Ważny, powód to uniwersalność takiego rozwiązania. Nie musisz hardocodować konkretnego obiektu w kodzie. Z perspektywy działania kodu, są identyczne, tu i tu musisz utworzyć obiekt. Patrząc jednak na wzorce projektowe czy przejrzystość kodu, stosowana powszechnie jest wersja A.
Rysh
http://phpedia.pl/wiki/Singleton dla wersji PHP5, można zrobić to samo do połączenia z bazą danych, będziesz miał pewność że utworzone zostało tylko jedno połączenie z bazą danych.
Damonsson
Nie wypowiem się osobiście, żeby nie rozpętać burzy, ale pamiętaj, że niektórzy uważają Singleton za antywzorzec. Ale to już sam musisz rozważyć wszelkie za i przeciw, których mnóstwo w sieci.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.