Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Formularz logowania OOP + PDO + Smarty
Forum PHP.pl > Forum > PHP > Object-oriented programming
_chris_
Witam wszystkich

Jako że się uczę całe życie i staram rozwijać, teraz stanąłem przed kolejnym zadaniem. Chciałem zrobić sobie prosty formularz logowania (bez rejestracji itd) wykorzystując OOP i PDO do połączenia z bazą danych. Nie bardzo mogę sobie poradzić z organizacją kodu. Stworzyłem sobie klasę:

  1. class Uzytkownik{
  2. var imie;
  3.  
  4. public function __construct($_imie){
  5. $this->imie = $_imie;
  6. }
  7.  
  8. }


Mam też klasę DB zaimplementowaną jako Singleton
  1. class DB{
  2. private username = "xxx";
  3. private password = "xxx";
  4. private host = "xxx";
  5. private dbName = "xxx";
  6.  
  7. public function __contruct(){
  8. $this->db = new PDO('mysql:host='.$host.';dbname='.$dbName, self::$username, self::$password);
  9. $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
  10. }
  11.  
  12. public static function getInstance(){
  13. if(!isset(self::$instance)){
  14. $object = __CLASS__;
  15. self::$instance = new $object;
  16.  
  17. }
  18. return self::$instance;
  19. }
  20. }


No i właśnie tutaj zaczynają się schody. Chciałbym mieć metodę do logowania. Czy ta metodę powinienem umieścić w klasie Użytkownika czy DB ? Jeśli w użytkowniku, to czy przypisywać zawsze użytkowniki instancję DB? Prosiłbym o pomoc, generalnie to opis tego jak Wy to robicie w swoich aplikacjach. Wiem że jak teraz źle coś zrobię, to potem poprawki będą ciężkie.

Generalnie najbardziej chodzi mi o rozwiązanie tego gdzie, co i w czym ma być w tych klasach żeby potem utworzenie formularza logowania zajęło raptem parę linijek, np
Index.php
  1. if(isset($_SESSION['uzytkownik']) $smarty->display('index.tpl');
  2. else header('location: login.php')

Login.php
  1. if(isset($_POST['submit']) if(zaloguj($_POST['login'], $_POST['password'])) header("location: index.php");
  2. else $smarty->display('login_form.tpl');


Z góry dziękuję za porady
pyro
Po pierwsze twój kod jest zupełnie bez sensu, bo przykładowo:
1. Nieprawidłowe odwołania do właściwości klasy
2. Singleton razem z publicznym konstruktorem, do którego brak zresztą odwołania.
3. Tworzenie niepotrzebnych zalezności od innych klas
4. itd....

Co do głównego wątku: logowanie, rejestracja, obsługa użytkownika itp. to powinny być oddzielne klasy, a nie kolejne metody.
_chris_
Cytat(pyro @ 9.04.2013, 13:06:43 ) *
Po pierwsze twój kod jest zupełnie bez sensu, bo przykładowo:
1. Nieprawidłowe odwołania do właściwości klasy
2. Singleton razem z publicznym konstruktorem, do którego brak zresztą odwołania.
3. Tworzenie niepotrzebnych zalezności od innych klas
4. itd....

Co do głównego wątku: logowanie, rejestracja, obsługa użytkownika itp. to powinny być oddzielne klasy, a nie kolejne metody.


1. No nie ma odwołan nie chciałem kopiować tutaj wszystkiego.
2. Oczywista oczywistość... Moje niedopatrzenie
3. No właśnie to jak to zrobić jest takie moje pytanie?

Co ma być w użytkowniku, czy ma mieć jakies metody, czy te metody do DB przenieść? Nie proszę o wytykanie tylko błędów, ale o naprowadzenie jak to zrobić poprawnie.
!*!
Cytat(_chris_ @ 9.04.2013, 14:09:44 ) *
Nie proszę o wytykanie tylko błędów, ale o naprowadzenie jak to zrobić poprawnie.


Jak użyjesz wyszukiwarki na forum (tej google) z frazą "logowanie OOP", masz kilkanaście tematów z tym związanych i w prawie każdym drugie tyle odpowiedzi, które z pewnością rozwieją wszelkie wątpliwości.
pyro
A wytykanie błędów to nie jest naprowadzanie jak zrobić poprawnie?

1. Połączenie mógłbyś zaaplikować za pomocą Dependency Injection
2. To samo z logowaniem, rejestracją, itp.
_chris_
Czyli rozumiem, że dla każdej akcji: logowanie, rejestracja, przypominanie hasła mam mieć osobną klasę? Ja trochę poszedłem tokiem myślenia MVC, tak jak jest w cakePHP, a tam po prostu poszczególne operacje są funkcjami i stąd taki mój początek. Potem coś zmodzę, będę prosił o ocenę.
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.