baza danych koncepcja obiektowa Opcje

[collecter]

Poniewaz dopiero od niedawna mam stycznosc z objektowym projektowaniem w php, mam jedno pytanie ktore przysparza mie sporo trudnosci. Dotyczy ono polaczenia z baza danych i pozniejszego jego wykorzystywania. Zalozmy ze mamy kilka klas korzystajacych z bazy danych. Czy w waszych aplikacjach na poczatku pliku tworzycie polaczenie ( za pomoca funkcji mysql connect ) i dolaczacie ten plik do kazdej strony, a w waszych klasach zakladacie ze polaczenie zostalo juz wczesniej otwarte i uzywacie komend mysql query a na koncu strony zalozmy w pliku footer.php zamykacie polaczenie? Czy moze tworzycie klase mysql z komendami query itd. I kazda klasa korzysta z jej instancji i metod.

Chcac dac przyklad zeby to lepiej zobrazowac zalozmy ze mam klase User i metode setName. Czy w metodzie setName uzywacie bezposrednio komendy mysql update liczac ze polaczenie zostalo otwarte wczesniej (nie w tej klasie, a dolaczone w pliku do kazdej strony) czy moze w tej metodzie tworzycie instancje klasy MYSQL (stworzonej przeze mnie i np laczycie sie z baza w konstruktorze) i korzystacie z jej metod zeby wykonac operacje na bazie danych.

Mam nadzieje ze nie zagmatwalem tego za bardzo.

[Crozin]

1. Od połączenia z bazą danych w PHP masz PDO, a nie mysql_connect.
2. Stan globalny (funkcje mysql_*() na nim operują) jest nienaturalny dla programowania obiektowego. Za każdym razem, gdy zaczynasz korzystać z czegoś globalnego można śmiało powiedzieć, że na 99% masz coś zrypanego.
3. Google: oop dependency injection

[pyro]

1. Od połączenia z bazą danych w PHP masz PDO, a nie mysql_connect.

Nigdy nie widziałem wiarygodnego wpisu, który by mówił o tym, że to PDO jest zwierzchnikiem połączeń z MySQL. Równie dobrze można użyć MySQLi, które nawet lepiej się sprawdzi w połączeniach z MySQL. (jest szybszy).

@collecter, połączeń z bazą danych powinno być jak najmniej. Jeśli to możliwe to najlepiej tylko jedno, które jak sam powiedziałeś może być w innym pliku, a ten plik może być potem dołączany do skryptu. Jakbyś pooglądał strukturę plików niektórych systemów opartych na PHP to byś zobaczył nieraz plik a'la db.php / conn.php / config.php, który najczęściej właśnie odpowiada za połączenie z bazą danych.

[Crozin]

Nigdy nie widziałem wiarygodnego wpisu, który by mówił o tym, że to PDO jest zwierzchnikiem połączeń z MySQL. Równie dobrze można użyć MySQLi, które nawet lepiej się sprawdzi w połączeniach z MySQL. (jest szybszy).

Nie napisałem, że nie może użyć niczego poza PDO. Nie mniej jednak to właśnie PDO jest standardem i to ono jest obsługiwane przez znakomitą większość zewnętrznych bibliotek (nawet tych stricte nastawionych na MySQL).

[smentek]

Jakąkolwiek warstwę abstrakcji wybierzesz (PDO jest bardziej nowoczesne) ważne jest aby dostęp do niej następował przez obiektowy interfejs, oraz aby nie inicjalizować połączenia cześciej niż to konieczne, a także nie tworzyć nadmiarowych instancji obiektu obsługującego połączenie.

Najprostsze rozwiązanie (nie znaczy najlepsze): Opakowujesz obiekt z połączeniem do bazy w singleton, (tylko jedna instancja) tak że siedzi on sobie jako zmienna w nowo utworzonej klasie. W konstruktorze lub w którejś metod wywoływanych w konstruktorze ustawiasz połączenie którego używasz później. W ten sposób możesz go wyciągnąć w dowolnym miejscu w swoim systemie.

Oczywiście twój obiekt nie powinien powielać całego interfejsu PDO. Służy jedynie inicjalizacji połączenia, wszystkie metody są wywoływane na właściwym obiekcie z ustawionym połączeniem.

Tą samą funkcjonalność można osiągnąć bez singletonu, ale jest to już trudniejsze do osiągnięcia, ponieważ wymaga przekazywania obiektu jako zmiennej do miejsc w których będzie wykorzystywany.

[Inscure]

Trzeba zacząć od tego, że funkcje mysql_ nie są już zalecane do używania, w szczególnie jeśli chodzi o programowanie obiektowe.
Dużo lepszym rozwiązaniem jest skorzystanie z biblioteki PHPDataObject.
Sposób jej wykorzystania i część odpowiedzi na Twoje pytania zawarłem w krótkim artykule (jeśli mogę tak go nazwać) dotyczącym:

- łączenia z bazą;
- przekazywania instancji do kolejnych klas;

Zachęcam do analizy:

http://page-manager.com/forum/viewtopic.ph...9277228f31c061f

Sposób pobierania danych, zamieszczania, usuwania itd znajduję się tu:

http://pl.wikibooks.org/wiki/PHP/Biblioteka_PDO

Ten post edytował Inscure 29.04.2011, 22:26:48

[Zyx]

Witaj Inscure, na Twoją prośbę przesłaną przez PW odpowiadam krótko: tę ideę można o kant czterech liter rozbić, bo z programowaniem obiektowym ma ona tyle wspólnego, co piernik z wiatrakiem. Po co Ci obiekty, skoro później budujesz na niej emulację zwykłego kodu proceduralnego? Po co w tej emulacji kodu tworzysz obiekt, który operuje jedynie na elemencie statycznym? Nie lepiej wszystko zrobić statycznie? Wreszcie, jak już robisz coś singletonopodobnego, to nazwij to odpowiednio. Wypadałoby też przeczytać krytykę tego wzorca projektowego.

Do zarządzania obiektami w aplikacji wymyślono całą masę elastyczniejszych i wyspecjalizowanych rozwiązań. Zamiast wyważać otwarte drzwi i tworzyć programistyczne potworki, poczytaj sobie o takich zagadnieniach, jak Dependency Injection. Jeśli zaś chodzi o magię, polecam to:

http://www.zyxist.com/pokaz.php/harryemu_juz_podziekujemy

[Inscure]

Zastanawiałem się nad dwoma typami rozwiązań problemu korzystania z metod jednej klasy w drugiej.
Oprócz powyższego rozwiązania miałem do dyspozycji wstrzykiwanie obiektu do klasy przez konstruktor.

Wybierając pierwszy sposób, w celach testowych i poznania opinii (między innymi Twojej), utworzyłem obiekt w z dwóch powodów:

- aby móc korzystać z metod obiektu w innej klasie bez dodatkowej roboty (ładowania do konstruktora zmiennej obiektu)
- poza klasami, używać $_sql->metoda();

Czekając na wypowiedź, trochę zastanawiałem się nad sensem tego rozwiązania i doszedłem właściwie do podobnych wniosków.
Rzeczywiście, lepszym rozwianiem jest zdecydowanie się, czy wszędzie korzystam w sposób statyczny z metod, czy może przeciwnie.

Obecnie robi się bałagan, bo emulacja statyczności jest jak wspomniałeś, nawiązaniem do Harrego
Pojawia się jednak problem sfery PDO - metody tej klasy nie są statyczne (przynajmniej query()).

W związku z tym mam zamiar poprawić to w sposób taki, że będę wstrzykiwał zmienną obiektu do konstruktorów.
W innym wypadku, gdybym wszystko zrobił statycznie, to wraz wyszłoby na to samo, bo emulowałbym statyczność dla query().

Jakbym źle kombinował, proszę zwrócić mi uwagę
Dziękuję za opinię.

Ten post edytował Inscure 1.05.2011, 17:44:43

[pejott]

Ja bym zdecydowanie zrezygnował z metod statycznych, ze względu że nie da się ich testować.
Jest wiele rozwiązań, ale według mnie najlepsze to właśnie DependencyInjection.
Stwórz obiekt połączenia z bazą a potem przekazuj go czy to setterami, czy w konstruktorze innych obiektów.

Pozdrawiam.