[PHP] Object geörienteerd - database select

[Verwijderd]

Ik heb zelf een nieuw bestand gemaakt en opnieuw een stukje code geschreven.
Dit na alle reacties te hebben gelezen. Tijdens het schrijven van de code niet op Tweakers gekeken om het even echt geheel zelf te proberen.

Het volgende komt eruit en het werkt.

PHP:

<?php
class Student{
    public $voornaam;
    public $studentnummer;
}
class Student_Repository{
    private $_db;
    
    public function __construct($db){
        $this->_db = $db;
    }
    
    public function getAllStudents(){
        try{
            $result = $this->_db->prepare("SELECT * FROM student");
            $result->execute();
            
            $mapper = new Record_To_Student();
            
            $outputList = array();
            
            while($record = $result->fetch()){
                $student = new Student();
                
                $mapper->mapper($record, $student);
                
                $outputList[] = $student;
            }
            
            return $outputList;
        }
        catch(PDOException $err){
            return false;
        }
    }
}
class Record_To_Student{
    public function mapper($record, $student){
        $student->voornaam = $record['voornaam'];
        $student->studentnummer = $record['studentnummer'];
    }
}

try{
    $pdo = new PDO('mysql:host=localhost;dbname=student;port=port', 'user', 'pass');
    $student = new Student_Repository($pdo);
    
    $students = $student->getAllStudents();
    
    if(!$students){
        echo 'Er is een fout opgetreden!';
    }
    else{
        print_r($students);
    }
}
catch(PDOException $err){
    echo 'Er is iets fout gegaan!';
}

Ik hoor graag wat jullie er van vinden.

Wat is nou eigenlijk het daadwerkelijke doel van een mapper? Ik heb het hier gebruikt, maar ik zou toch ook een array van de resultaten uit de query kunnen maken en die direct returnen?

Ik hoor het graag

[ Voor 2% gewijzigd door Verwijderd op 08-11-2016 19:07 . Reden: Correctie ]

[Verwijderd]

Verwijderd schreef op dinsdag 08 november 2016 @ 19:02:
Wat is nou eigenlijk het daadwerkelijke doel van een mapper?

In dit geval? Geen idee...

[douchekip]

Het nut van een "Mapper" is om platte data (in dit geval uit de database) om te zetten naar een in-memory representatie waar het programma mee kan werken (in dit geval een Student object), en vice versa.

In het voorbeeld is de data structuur 1:1 gelijk aan de velden van de Student class, dus is de losse Record_To_Student mapper een beetje overkill.


Een iets versimpelde uitleg:
Mappers zijn om data heen en weer te converteren.
Repositories zijn queries te bouwen.


In jouw voorbeeld heb je eigenlijk al iets te veel 'converteer' code in je repository.

[ Voor 24% gewijzigd door douchekip op 08-11-2016 20:24 ]

[incaz]

Het doel van een de map-functie is het omzetten van een array (dat je terugkrijgt van de db) naar een object (de student.)

Het doel van OO is dat je de objecten gebruikt om verder mee te werken. Over een tijdje wil je het programma bv uitbreiden en schrijf je een functie die aan een Student een Opdracht mee kan geven. Dat is veel duidelijker dan als je zegt 'aan een array een array meegeven.' Als je weet dat iets een Student is, weet je bv dat je te maken hebt met studentnummers en voornamen. Als je weet dat iets een Opdracht is, kun je dingen verwachten als 'titel' en 'sluitdatum' - maar geen voornaam.

Objecten zijn dus om dat gebruik helder te maken.

Dan je repository: dat is een object dat communiceert met de database en je een verzameling studenten (of een losse student) teruggeeft.
Dat is niet hetzelfde als een Student zelf, de repository zelf heeft geen studentnummer of voornaam, en gaat geen Opdrachten inleveren. In dit geval is het gebruik van de variabelenaam $student voor een repository-object dus wat verwarrend.

In dit geval zou ik dus denken dat het laatste deel van de code logischer is met een naamgeving als volgt:

PHP:

$student_repo = new Student_Repository($pdo);
    
$students = $student_repo->getAllStudents();

// en dan iets als 
foreach( $students as $student){
   // hier kun je dan iets met elke $student doen. 
}

Tot slot kun je de mapper-functie opnemen in de repository-class. Dat hoort ook allemaal qua functionaliteit bij elkaar: het gaat om de verbinding tussen de database en je object.

[HollowGamer]

incaz schreef op dinsdag 08 november 2016 @ 20:38:
[..]

Vind het allemaal wat ver gaan, begin gewoon bij het begin van OOP.
Het leren van de magic_methods autoloading, extends, interface, etc. lijkt mij veel beter.

[ThomasG]

Je kunt natuurlijk ook te ver doorschieten met OOP. Wat het belangrijkste is, is dat je goed gebruikt maakt van de functionaliteit van de gebruikte programmeertaal. Veel design-patterns en andere OOP constructies zijn voor oorspronkelijk bedoeld voor Java, omdat er in Java vaak geen andere manier is om het correct te doen. In PHP gelden andere OOP regels, die niet in lijn zijn met die van bijvoorbeeld Java, maar daardoor niet fout.

[incaz]

HollowGamer schreef op dinsdag 08 november 2016 @ 21:12:
[...]

Vind het allemaal wat ver gaan, begin gewoon bij het begin van OOP.
Het leren van de magic_methods autoloading, extends, interface, etc. lijkt mij veel beter.

Het begin van OOP? Brr, nee hoor. Het begin van OOP is dat het gaat om objecten.
Magic_methods en autoloading zijn vooral handigheidjes (en neem daar vooral een framework voor, dan krijg je namelijk nog heel veel andere handigheidjes er gratis en voor niets bij) maar hebben niets met de basis van OOP te maken.
Extends en interface zijn wel fundamenteel als je wat feeling krijgt wat een object uberhaupt is, maar voorlopig nog niet. En dat is ook niet de core van OOP.

[Barryvdh]

Verwijderd schreef op dinsdag 08 november 2016 @ 19:02:

Wat is nou eigenlijk het daadwerkelijke doel van een mapper? Ik heb het hier gebruikt, maar ik zou toch ook een array van de resultaten uit de query kunnen maken en die direct returnen?

Ik hoor het graag

Je kan ook gewoon PDO je resultaat direct laten mappen naar je class:

PHP:

class StudentRepository
{
    /** @var PDO $_db */
    private $_db;

    public function __construct(PDO $db) 
    {
        $this->_db = $db;
    }

    public function getAllStudents()
    {
        $result = $this->_db->prepare("SELECT * FROM student");
        $result->setFetchMode(PDO::FETCH_CLASS, Student::class);
        $result->execute();

        return $result->fetchAll();
    }
}

Dan heb je die Record_To_Student class + die foreach loop helemaal niet nodig.
Leer je overigens ook meteen aan je constructor argumenten te typehinten, zodat het duidelijk is wat je verwacht. Tevens kan je IDE je dan nuttige meldingen geven.

En natuurlijk zou je, om OOP te oefenen, een BaseRepository kunnen maken, die bijvoorbeeld de DB constructor + ophalen van resultaten (1 of meerdere) doet, terwijl je dan in je StudentRepository alleen bijv. '$this->fetchRows("SELECT * FROM student")' hoeft te doen.

Edit: zoiets dus:

PHP:

abstract class BaseRepository
{
    private $_db;
    protected $classname;

    public function __construct(PDO $db)
    {
        $this->_db = $db;
    }

    public function fetch($query, $parameters = [])
    {
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);

        return $result->fetch();
    }

    public function fetchAll($query, $parameters = [])
    {
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);

        return $result->fetchAll();
    }
}

class StudentRepository extends BaseRepository
{
    protected $classname = Student::class;

    /**
     * @return array|Student[]
     */
    public function getAllStudents()
    {
        return $this->fetchAll("SELECT * FROM student");
    }

    /**
     * @param int $nummer
     * @return Student
     */
    public function getStudent($nummer)
    {
        return $this->fetch("SELECT * FROM student WHERE `studentnummer` = :nummer LIMIT 0,1", [':nummer' => $nummer]);
    }
}

(Al kan je misschien beter je values expliciet binden met bindParam om het goede type te krijgen)

En als je dan echt pietje precies wil zijn, ga dan meteen voor PSR-1 + PSR-2 styling, dus StudentRepository ipv Student_Repository, en andere braces etc.

[ Voor 28% gewijzigd door Barryvdh op 08-11-2016 23:59 ]

[Bee.nl]

HollowGamer schreef op dinsdag 08 november 2016 @ 21:12:
magic_methods

Magic methods moet je niet te scheutig mee zijn. Het maakt het debuggen en opsporen van usages lastiger. Er zijn uiteraard handige use cases voor, maar by default kun je properties en methods het best expliciet definiëren. Een goede IDE (PhpStorm) kan deze automatisch voor je genereren.

ThomasG schreef op dinsdag 08 november 2016 @ 21:19:
Je kunt natuurlijk ook te ver doorschieten met OOP. Wat het belangrijkste is, is dat je goed gebruikt maakt van de functionaliteit van de gebruikte programmeertaal. Veel design-patterns en andere OOP constructies zijn voor oorspronkelijk bedoeld voor Java, omdat er in Java vaak geen andere manier is om het correct te doen. In PHP gelden andere OOP regels, die niet in lijn zijn met die van bijvoorbeeld Java, maar daardoor niet fout.

Niet mee eens. Design patterns zijn niet gebonden aan een taal. Het zijn blauwdrukken van bepaalde gedragingen/constructies die ingezet kunnen worden tot het oplossen/huisvesten van bepaalde probleemstukken. Iedere taal heeft zo zijn eigen implementatiedetails op het gebied van OOP, maar in grote lijnen blijft het gedachtegoed hetzelfde.

[ThomasG]

Bee.nl schreef op dinsdag 08 november 2016 @ 21:29:
[...]

Magic methods moet je niet te scheutig mee zijn. Het maakt het debuggen en opsporen van usages lastiger. Er zijn uiteraard handige use cases voor, maar by default kun je properties en methods het best expliciet definiëren. Een goede IDE (PhpStorm) kan deze automatisch voor je genereren.
[...]

Niet mee eens. Design patterns zijn niet gebonden aan een taal. Het zijn blauwdrukken van bepaalde gedragingen/constructies die ingezet kunnen worden tot het oplossen/huisvesten van bepaalde probleemstukken. Iedere taal heeft zo zijn eigen implementatiedetails op het gebied van OOP, maar in grote lijnen blijft het gedachtegoed hetzelfde.

Design patterns zijn niet perse gebonden aan een taal. Maar als je zoekt naar design patterns zijn de meeste ontworpen voor Java. Als je die zonder na te denken copy-paste in PHP, dan doe je gewoon iets niet goed. Want veel van de Gang of Four design patterns heb je óf niet nodig in PHP, óf kun je op een andere - in die taal efficiëntere - manier doen. Het wordt daardoor niet ineens minder OOP, enkel op een andere manier.

[Verwijderd]

HollowGamer schreef op dinsdag 08 november 2016 @ 21:12:
[...]

Vind het allemaal wat ver gaan, begin gewoon bij het begin van OOP.
Het leren van de magic_methods autoloading, extends, interface, etc. lijkt mij veel beter.

Ik ben al een weekje bezig met OOP.
Ik heb diverse tutorials gevolgd waarin de magic_methods, extends en interface terugkwamen .

Ik wil me nu alleen (misschien te snel) verdiepen in OOP en databases.

[Barryvdh]

Verwijderd schreef op dinsdag 08 november 2016 @ 21:45:
[...]


Ik ben al een weekje bezig met OOP.
Ik heb diverse tutorials gevolgd waarin de magic_methods, extends en interface terugkwamen .

Ik wil me nu alleen (misschien te snel) verdiepen in OOP en databases.

Vergeet vooral ook niet PHP The Right Way even door te kijken (is volgens mij nog niet langs gekomen)

http://www.phptherightway.com/

Staat ook een (beknopt) stuk over Databases, Dependency Injection, Design Patterns en natuurlijk Security.

[Verwijderd]

Barryvdh schreef op dinsdag 08 november 2016 @ 21:27:
[...]


Je kan ook gewoon PDO je resultaat direct laten mappen naar je class:

PHP:

class StudentRepository
{
    /** @var PDO $_db */
    private $_db;

    public function __construct(PDO $db) 
    {
        $this->_db = $db;
    }

    public function getAllStudents()
    {
        $result = $this->_db->prepare("SELECT * FROM student");
        $result->setFetchMode(PDO::FETCH_CLASS, Student::class);
        $result->execute();

        return $result->fetchAll();
    }
}

Dan heb je die Record_To_Student class + die foreach loop helemaal niet nodig.
Leer je overigens ook meteen aan je constructor argumenten te typehinten, zodat het duidelijk is wat je verwacht. Tevens kan je IDE je dan nuttige meldingen geven.

En natuurlijk zou je, om OOP te oefenen, een BaseRepository kunnen maken, die bijvoorbeeld de DB constructor + ophalen van resultaten (1 of meerdere) doet, terwijl je dan in je StudentRepository alleen bijv. '$this->fetchRows("SELECT * FROM student")' hoeft te doen.

Edit: zoiets dus:

PHP:

abstract class BaseRepository
{
    private $_db;
    protected $classname;

    public function __construct(PDO $db)
    {
        $this->_db = $db;
    }

    public function fetch($query, $parameters = [])
    {
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);

        return $result->fetch();
    }

    public function fetchAll($query, $parameters = [])
    {
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);

        return $result->fetchAll();
    }
}

class StudentRepository extends BaseRepository
{
    protected $classname = Student::class;

    /**
     * @return array|Student[]
     */
    public function getAllStudents()
    {
        return $this->fetchAll("SELECT * FROM student");
    }

    /**
     * @param $id
     * @return Student
     */
    public function getStudent($id)
    {
        return $this->fetch("SELECT * FROM student WHERE `id` = :id LIMIT 0,1", [':id' => $id]);
    }
}

(Al kan je misschien beter je values expliciet binden met bindParam om het goede type te krijgen)

En als je dan echt pietje precies wil zijn, ga dan meteen voor PSR-1 + PSR-2 styling, dus StudentRepository ipv Student_Repository, en andere braces etc.

Super bedankt! Ik ga er even mee knutselen!

Barryvdh schreef op dinsdag 08 november 2016 @ 21:50:
[...]

Vergeet vooral ook niet PHP The Right Way even door te kijken (is volgens mij nog niet langs gekomen)

http://www.phptherightway.com/

Staat ook een (beknopt) stuk over Databases, Dependency Injection, Design Patterns en natuurlijk Security.

Bedankt voor de link, deze was inderdaad nog niet genoemd!

[Verwijderd]

Goed, ik ben even bezig geweest.
Ik heb er voor gekozen om terug terug te gaan naar MYSQLI, hiermee heb ik op dit moment de meeste ervaring dus wil ik eerst daarmee oefenen.

PHP:

<?php
class Student 
{
    public $voornaam;
    public $studentnummer;
}


abstract class BaseRepository
{
    protected $_db;
    protected $_classname;
    
    public function __construct(MYSQLI $db)
    {
        $this->_db = $db;
    }
    
    public function fetchAll($query){
        $result = $this->_db->query($query);
        $result->fetch_object($this->_classname);
        return $result->fetch_all();
    }   
}

class StudentRepository extends BaseRepository
{
    protected $_classname = 'Student';
    
    public function getAllStudents()
    {
        return $this->fetchAll("SELECT * FROM student");
    }
    
    public function getStudent($studentnummer){
        if(is_int($studentnummer)){
            $studentnummer = $this->_db->real_escape_string($studentnummer);
        
            return $this->fetchAll("SELECT * FROM student WHERE studentnummer='".$studentnummer."'");
        } else{
            echo 'Studentnummer moet een getal zijn!';
        }
    }
}

$mysqli = new mysqli("localhost", "user", "pass", "student");

if(mysqli_connect_errno()){
    echo 'Er is een fout opgetreden!';
} else{
    $studentRepository = new StudentRepository($mysqli);
    $student = $studentRepository->getStudent(1000200);
    print_r($student);
}

Als ik bij 'getStudent' zeg dat het studentnummer gelijk moet zijn aan het opgegeven studentnummer krijg ik als output: Array(). Als ik zeg dat deze ongelijk moet zijn aan het opgegeven studentnummer krijg ik wel een output.
Hoe kan dat?

[Barryvdh]

Verwijderd schreef op dinsdag 08 november 2016 @ 23:10:
Goed, ik ben even bezig geweest.
Ik heb er voor gekozen om terug terug te gaan naar MYSQLI, hiermee heb ik op dit moment de meeste ervaring dus wil ik eerst daarmee oefenen.

PHP:

<?php
class Student 
{
    public $voornaam;
    public $studentnummer;
}


abstract class BaseRepository
{
    protected $_db;
    protected $_classname;
    
    public function __construct(MYSQLI $db)
    {
        $this->_db = $db;
    }
    
    public function fetchAll($query){
        $result = $this->_db->query($query);
        $result->fetch_object($this->_classname);
        return $result->fetch_all();
    }   
}

class StudentRepository extends BaseRepository
{
    protected $_classname = 'Student';
    
    public function getAllStudents()
    {
        return $this->fetchAll("SELECT * FROM student");
    }
    
    public function getStudent($studentnummer){
        if(is_int($studentnummer)){
            $studentnummer = $this->_db->real_escape_string($studentnummer);
        
            return $this->fetchAll("SELECT * FROM student WHERE studentnummer='".$studentnummer."'");
        } else{
            echo 'Studentnummer moet een getal zijn!';
        }
    }
}

$mysqli = new mysqli("localhost", "user", "pass", "student");

if(mysqli_connect_errno()){
    echo 'Er is een fout opgetreden!';
} else{
    $studentRepository = new StudentRepository($mysqli);
    $student = $studentRepository->getStudent(1000200);
    print_r($student);
}

Als ik bij 'getStudent' zeg dat het studentnummer gelijk moet zijn aan het opgegeven studentnummer krijg ik als output: Array(). Als ik zeg dat deze ongelijk moet zijn aan het opgegeven studentnummer krijg ik wel een output.
Hoe kan dat?

Omdat je het resultaat al ophaalt met '$result->fetch_object($this->_classname);' maar er verder niks mee doet. Daarna roep je nogmaals een fetch aan, maar heb je alle resultaten al opgehaald.

Maar doe dit nou niet. Vergeet mysqli, gebruik gewoon PDO met prepared statements. Of in het uiterste geval mysqli maar dan wel met Prepared statements. Eenmaal aangeleerd is moeilijk af te leren.

(En stop dan ook meteen met properties prefixen met een underscore, mag ook niet volgens PSR-2)

Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.

Dat is een overblijfsel van toen er nog geen protected/private keywords waren..

[mrBako]

Offtopic:
Hoewel ik weinig ervaring heb met php zie ik iets verdachts aan de queries die je opbouwt.
Leer jezelf aan om met parameters te werken en niet via if statements waarin geparsed wordt.
Zo verklein(lees voorkom) je SQL injections.

[Verwijderd]

Barryvdh schreef op woensdag 09 november 2016 @ 00:08:
[...]


Omdat je het resultaat al ophaalt met '$result->fetch_object($this->_classname);' maar er verder niks mee doet. Daarna roep je nogmaals een fetch aan, maar heb je alle resultaten al opgehaald.

Maar doe dit nou niet. Vergeet mysqli, gebruik gewoon PDO met prepared statements. Of in het uiterste geval mysqli maar dan wel met Prepared statements. Eenmaal aangeleerd is moeilijk af te leren.

(En stop dan ook meteen met properties prefixen met een underscore, mag ook niet volgens PSR-2)

[...]

Dat is een overblijfsel van toen er nog geen protected/private keywords waren..

Oké, bedankt. Ik zal later vandaag het aanpassen en mijn nieuwe code posten!

[4Real]

Dit,


Dat,
http://stackoverflow.com/...vent-sql-injection-in-php

En nog wat,
http://php.net/manual/en/pdo.prepared-statements.php

Verplicht leesvoer!

[Verwijderd]

Goed, ik heb nu deze code weer:

PHP:

<?php
class Student
{
    public $voornaam;
    public $studentnummer;
}
abstract class BaseRepository
{
    private $_db;
    protected $classname;
    
    public function __construct(PDO $db){
        $this->_db = $db;
    }
    
    public function fetch($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetch();
    }
    public function fetchAll($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetchAll();
    }
}
class StudentRepository extends BaseRepository
{
    protected $classname = 'student';
    
    public function getAllStudents()
    {
        return $this->fetchAll("SELECT studentnummer, voornaam FROM student");
    }
    
    public function getStudent($studentnummer)
    {
        return $this->fetch("SELECT * FROM student WHERE studentnummer = :nummer LIMIT 0,1", [':nummer' => $studentnummer]);
    }
}

try{
    $pdo = new PDO('mysql:host=localhost;dbname=student;port=port', 'user', 'pass');
    $student = new StudentRepository($pdo);
    
    $student1 = $student->getStudent('S1001902');
    
    if(!$student1){
        echo 'Er is een fout opgetreden bij het ophalen van de student!';
    }
    else{
        print_r($student1);
    }
}
catch(PDOException $err){
    echo 'Er is iets fout gegaan!'.$err;
}

Als ik het goed begrijp kan ik dus nu de voornaam van deze student als volgt weergeven:

PHP:

echo $student1->voornaam;

Het verschil is dus dat je nu een object terug krijgt als data ipv een array (bv)?

En:

PHP:

$students = $student->getAllStudents();

foreach($students as $student){
    echo $students->voornaam.'<br>';
}

[ Voor 5% gewijzigd door Verwijderd op 09-11-2016 19:29 ]

[Barryvdh]

Verwijderd schreef op woensdag 09 november 2016 @ 19:26:

Als ik het goed begrijp kan ik dus nu de voornaam van deze student als volgt weergeven:

PHP:

echo $student1->voornaam;

Het verschil is dus dat je nu een object terug krijgt als data ipv een array (bv)?

En:

PHP:

$students = $student->getAllStudents();

foreach($students as $student){
    echo $students->voornaam.'<br>';
}

Bijvoorbeeld ja, maar nu je een object hebt kan je daar ook meer mee. In huidige vorm is het niet zo spannend, maar je zou bijvoorbeeld aan zoiets kunnen denken:

PHP:

class Student
{
    public $voornaam;
    public $achternaam;
    public $studentnummer;

    public function getFullName()
    {
        return $this->voornaam . ' ' . $this->achternaam;
    }

    public function hasValidNumber()
    {
        return substr($this->studentnummer, 0, 1) == 'S';
    }
}

Dan is je Student dus je 'Model' dat data bevat maar ook bepaalde methodes om iets nuttigs te doen met de data (in plaats van dat in je templates/weergave code te doen.

En omdat je met objecten werkt, kan je ook wederom typehints gebruiken, zodat je zeker weet dat je een bepaald object hebt.

PHP:

class School
{
    protected $students = [];

    public function addStudent(Student $student)
    {
        $this->students[] = $student;
    }
}

$student1 = $student->getStudent('S1001902');
    
$school = new School();
$school->addStudent($student1);

Dat zou dus een fout geven als je er een andere class in probeert te stoppen.

[Verwijderd]

Barryvdh schreef op woensdag 09 november 2016 @ 20:08:
[...]


Bijvoorbeeld ja, maar nu je een object hebt kan je daar ook meer mee. In huidige vorm is het niet zo spannend, maar je zou bijvoorbeeld aan zoiets kunnen denken:

PHP:

class Student
{
    public $voornaam;
    public $achternaam;
    public $studentnummer;

    public function getFullName()
    {
        return $this->voornaam . ' ' . $this->achternaam;
    }

    public function hasValidNumber()
    {
        return substr($this->studentnummer, 0, 1) == 'S';
    }
}

Dan is je Student dus je 'Model' dat data bevat maar ook bepaalde methodes om iets nuttigs te doen met de data (in plaats van dat in je templates/weergave code te doen.

En omdat je met objecten werkt, kan je ook wederom typehints gebruiken, zodat je zeker weet dat je een bepaald object hebt.

PHP:

class School
{
    protected $students = [];

    public function addStudent(Student $student)
    {
        $this->students[] = $student;
    }
}

$student1 = $student->getStudent('S1001902');
    
$school = new School();
$school->addStudent($student1);

Dat zou dus een fout geven als je er een andere class in probeert te stoppen.

Bedankt! Ik begrijp nu ook waarom het handig is om de resultaten om te zetten naar een object!

Maar de classes, maak je hiervoor per class een apart PHP bestand aan die je vervolgens include/require? Of maak je een algmeen bestand met alle classes die je include/require?

En de naam student in het onderstaand voorbeeld is eigenlijk niet juist voor deze variabele, zoals iemand al eerder aangaf in dit topic. Zal studentRepository een goede naam zijn?

PHP:

$student = new studentRepository($pdo);
$students = $student->getAllStudents();

[Barryvdh]

Verwijderd schreef op woensdag 09 november 2016 @ 22:42:
[...]


Bedankt! Ik begrijp nu ook waarom het handig is om de resultaten om te zetten naar een object!

Maar de classes, maak je hiervoor per class een apart PHP bestand aan die je vervolgens include/require? Of maak je een algmeen bestand met alle classes die je include/require?

En de naam student in het onderstaand voorbeeld is eigenlijk niet juist voor deze variabele, zoals iemand al eerder aangaf in dit topic. Zal studentRepository een goede naam zijn?

PHP:

$student = new studentRepository($pdo);
$students = $student->getAllStudents();

Conventie is om per class 1 bestand aan te maken. In PHP kan je dan een zogenaamde autoload gebruiken die alle classes voor je laadt, zoals PSR-4.
Je hebt in PHP ook namespaces, dus dan krijg je grofweg zoiets:

Namespace App -> mapje src/
class App\Models\Student -> src/Models/Student.php
class App\Repositories\StudentRepository -> src/Repositories/StudentRepository.php

in je index.php laad je dan de autoloader, daarna kan je gewoon new App\Models\Student() doen. Makkelijkste is om dit met Composer te doen, omdat je dat waarschijnlijk toch wil gebruiken later; https://getcomposer.org/
Zie bijvoorbeeld https://laracasts.com/lessons/psr-4-autoloading

Maar als dat wat te complex voor nu is, kan je ook gewoon je autoloader registreren: http://php.net/manual/en/function.spl-autoload-register.php

PHP:

spl_autoload_register(function ($class) {
    include 'src/' . $class . '.php';
});

Elke keer als je dan een class probeert aan te maken/gebruiken, zoek hij in src/<class naam>.php naar het bestand.

En ja, je naam is niet zo handig, beter zoiets:

PHP:

$studentRepository = new StudentRepository($pdo);
$students = $studentRepository->getAllStudents();
$student = $studentRepository->getStudent('S0123');

Of als je minder dubbelop wil doen:

PHP:

$studentRepository = new StudentRepository($pdo);
$students = $studentRepository->all();
$student = $studentRepository->findNumber('S0123');

[ Voor 4% gewijzigd door Barryvdh op 10-11-2016 10:02 ]

[Verwijderd]

Barryvdh schreef op donderdag 10 november 2016 @ 10:01:
[...]


Conventie is om per class 1 bestand aan te maken. In PHP kan je dan een zogenaamde autoload gebruiken die alle classes voor je laadt, zoals PSR-4.
Je hebt in PHP ook namespaces, dus dan krijg je grofweg zoiets:

Namespace App -> mapje src/
class App\Models\Student -> src/Models/Student.php
class App\Repositories\StudentRepository -> src/Repositories/StudentRepository.php

in je index.php laad je dan de autoloader, daarna kan je gewoon new App\Models\Student() doen. Makkelijkste is om dit met Composer te doen, omdat je dat waarschijnlijk toch wil gebruiken later; https://getcomposer.org/
Zie bijvoorbeeld https://laracasts.com/lessons/psr-4-autoloading

Maar als dat wat te complex voor nu is, kan je ook gewoon je autoloader registreren: http://php.net/manual/en/function.spl-autoload-register.php

PHP:

spl_autoload_register(function ($class) {
    include 'src/' . $class . '.php';
});

Elke keer als je dan een class probeert aan te maken/gebruiken, zoek hij in src/<class naam>.php naar het bestand.

En ja, je naam is niet zo handig, beter zoiets:

PHP:

$studentRepository = new StudentRepository($pdo);
$students = $studentRepository->getAllStudents();
$student = $studentRepository->getStudent('S0123');

Of als je minder dubbelop wil doen:

PHP:

$studentRepository = new StudentRepository($pdo);
$students = $studentRepository->all();
$student = $studentRepository->findNumber('S0123');

Bedankt!
Ik ga nu zelf proberen om een heel eenvoudig beheersysteem voor een website te maken, object georiënteerd te maken! (voorkant, en achterkant: pagina maken, aanpassen, verwijderen)
Niet object georiënteerd heb ik dit al vaak gedaan

[4Real]

Dan raad ik als nog aan om naar bestaande frameworks te kijken, want je maakt nu allemaal spul waar fouten in kunnen sluipen. Bijvoorbeeld niet parametizen van queries, en bij bestaand spul heb je al een goede basis, zodat je sneller resultaten kunt boeken. Anders ben je een jaar verder heb je een half framework en geen product.

[Tjolk]

4Real schreef op donderdag 10 november 2016 @ 16:53:
Dan raad ik als nog aan om naar bestaande frameworks te kijken, want je maakt nu allemaal spul waar fouten in kunnen sluipen. Bijvoorbeeld niet parametizen van queries, en bij bestaand spul heb je al een goede basis, zodat je sneller resultaten kunt boeken. Anders ben je een jaar verder heb je een half framework en geen product.

Allemaal leuk en aardig natuurlijk, maar volgens mij gaat het -NR- niet om het product. Hij wil snappen wat er gebeurd en WAAROM. En dan is dit een prima methode om jezelf wat wijzer te maken.

Anders kan-ie niet zo goed gewoon Wordpress installeren natuurlijk.

[Verwijderd]

4Real schreef op donderdag 10 november 2016 @ 16:53:
Dan raad ik als nog aan om naar bestaande frameworks te kijken, want je maakt nu allemaal spul waar fouten in kunnen sluipen. Bijvoorbeeld niet parametizen van queries, en bij bestaand spul heb je al een goede basis, zodat je sneller resultaten kunt boeken. Anders ben je een jaar verder heb je een half framework en geen product.

Het parametizen van een query heb ik niet in deze code toegepast inderdaad, maar normaal doe ik dat natuurlijk wel.
Verder heb ik het over een zeer simpel systeem, het is niet uitgebreid met een enorme database, we spreken over een systeem van maximaal 5 tabellen.

[Verwijderd]

Goed, ik heb het projectje gewijzigd naar een webshopje (simpele).

Ik heb hieronder een klein stukje code, ik hoor graag jullie mening
En hoe zou je nu rowCount(); kunnen doen?

PHP:

<?php
class Product
{
    public $productName;
    public $productDescription;
    public $unitPrice;
    public $discount;
    
    public function getProductName()
    {
        return htmlspecialchars($this->productName);
    }
    public function getPriceWithDiscount()
    {
        return $this->unitPrice - ($this->discount / 100);
    }
}

abstract class BaseRepository
{
    private $_db;
    protected $classname;
    
    public function __construct(PDO $db)
    {
        $this->_db = $db;
    }
    
    public function fetch($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetch();
    }
    public function fetchAll($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetchAll();
    }
}
class ProductRepository extends BaseRepository
{
    protected $classname = 'Product';
    
    public function getAllProducts()
    {
        return $this->fetchAll("SELECT productName, productDescription, unitPrice, discount FROM product");
    }
        public function getProductByID($id)
    {
        return $this->fetch("SELECT productName, productDescription, unitPrice, discount 
FROM product WHERE ID = :id", [':id' => $id]);
    }
}


try{
    $pdo = new PDO('mysql:host=localhost;dbname=webshop;port=port', 'user', 'pass');
    $productRepository = new ProductRepository($pdo);
    $products = $productRepository->getAllProducts();
    
    if(!$products){
        echo 'Er is een fout opgetreden bij het laden van de producten.';
    } 
    else{
        foreach($products as $product)
        {
            echo '<h1>'.$product->getProductName().'</h1><br>';
            echo $product->getPriceWithDiscount();
        }
        
    }

        $product = $productRepository->getProductByID(13);

    if(!$product){
               echo 'Product kon niet worden opgehaald!';
        } 

    unset($pdo);
}
catch(PDOException $err){
    echo 'Er is iets fout gegaan!'.$err;
}

[ Voor 8% gewijzigd door Verwijderd op 10-11-2016 18:37 ]

[mrBako]

Verwijderd schreef op donderdag 10 november 2016 @ 17:44:
En hoe zou je nu rowCount(); kunnen doen?

Zoals al eerder aangegeven ben ik niet ervaren met php, maar ik neem aan dat als je de getAllProducts() method aanroept ergens een array/list vult?
Php zal zeker een size_of of een count functie bevatten.

[Verwijderd]

mbakirci schreef op donderdag 10 november 2016 @ 23:51:
[...]


Zoals al eerder aangegeven ben ik niet ervaren met php, maar ik neem aan dat als je de getAllProducts() method aanroept ergens een array/list vult?
Php zal zeker een size_of of een count functie bevatten.

Dat klopt! Bedankt.
Ben alleen benieuwd hoe je de rowCount function van PDO nu het beste kan gebruiken.

[HollowGamer]

Wat is precies fout met een array gebruiken? Snap het punt van IDE's, maar waarom zou het niet mogen? Zeker tegenwoordig waar er steeds meer data bij komt, en het niet altijd hoeft te zijn dat een object alles bevat. Een studentmummer hoeft bijvoorbeeld nog niet zijn toegekend (toegeven dat dit niet wenselijk is), we weten nog niet alles over een student, etc. Moet je dan voor elk veld dit weer toevoegen aan de repository? 'Vroeger' had je nog beeld, maar steeds vaker komt er data bij/vallen stukjes weg, en gaan we naar steeds meer 'flexibele data'. Wat doe je als je van meerdere API's toch data wilt opslaan?
Het is toch goed mogelijk om data op te slaan als bijvoorbeeld JSON (zie NoSQL) en dit van (flexibele) keys te voorzien?

Niet om betweterig over te komem, maar zou het graag willen weten.

[ Voor 14% gewijzigd door HollowGamer op 11-11-2016 00:29 ]

[Barryvdh]

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
Wat is precies fout met een array gebruiken? Snap het punt van IDE's, maar waarom zou het niet mogen?

Mag best, maar we hebben het hier over 'Object oriented' en arrays zijn geen objecten
Een array zegt niks over de inhoud, maar een Student object geeft aan dat hij normaal gesproken voldoet aan een aantal verwachtingen qua velden en methodes. Daarnaast kan je dus aan dit 'Model' (om in MVC termen te spreken), extra methods toevoegen om het gebruik van die data makkelijker te maken (zie reactie van mij hier boven ergens).

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
Zeker tegenwoordig waar er steeds meer data bij komt, en het niet altijd hoeft te zijn dat een object alles bevat. Een studentmummer hoeft bijvoorbeeld nog niet zijn toegekend (toegeven dat dit niet wenselijk is), we weten nog niet alles over een student, etc. Moet je dan voor elk veld dit weer toevoegen aan de repository?

Dit maakt niet uit. Als die data als null in je database staat, of je neemt hem niet mee in je select, zal je in het geval van je Model ook 'null' krijgen. Bij een array krijg je, in het laatste geval, een undefined index in dit geval, terwijl je object in beide gevallen null is: https://3v4l.org/FeN9v

PHP:

class Student 
{
    public $studentnummer;
    public $voornaam;
}

$student = new Student();
$student->voornaam = 'Barry';

$data = ['voornaam' => 'Barry'];

var_dump(isset($student->studentnummer));  // false
var_dump(isset($data['studentnummer'])); // false

var_dump($student->studentnummer); // null
var_dump($data['studentnummer']); // undefined index

Ik weet niet welk veld je dan aan de repository moet toevoegen? Je bedoeld als property aan je Student class? Dat hoeft niet perse, maar is wel zo netjes. Anders werkt het ook gewoon: https://3v4l.org/FLHuK

PHP:

class Student 
{
    public $studentnummer;
    public $voornaam;
}

$student = new Student();
$student->achternaam = 'vd. H';

var_dump($student->achternaam); // vd. H

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
'Vroeger' had je nog beeld, maar steeds vaker komt er data bij/vallen stukjes weg, en gaan we naar steeds meer 'flexibele data'. Wat doe je als je van meerdere API's toch data wilt opslaan?
Het is toch goed mogelijk om data op te slaan als bijvoorbeeld JSON (zie NoSQL) en dit van (flexibele) keys te voorzien?

Ik weet niet precies wat voor 'beeld' we vroeger hadden, maar flexibele data is leuk, maar als je het wil verwerken zal je het toch moet mappen naar 'vaste' data. In dit geval wil je Student niet zien als ruwe data, maar als een representatie van een student. In dit (simpele) voorbeeld mappen we de database 1 op 1 naar het Student model, maar dit hoeft niet zo te zijn in grotere applicaties. Maar alsnog zul je een Model/value object willen maken waarvan je weet welke properties/methods het bevat. En met een class (of interface) kan je zorgen dat je dit 'contract' vast legt.

In dit voorbeeld zou je de data van een API natuurlijk gewoon kunnen mappen naar je Student class. Voor de verdere code maakt het dan niet uit of je data van een API, database of gegeneerd wordt. https://3v4l.org/HrP0O

PHP:

class Student 
{
    public $studentnummer;
    public $voornaam;
}

$apiResult = [
    'firstName' => 'Barry',
    'sid' => 'S123',
];

$map = [
    'firstName' => 'voornaam',
    'sid' => 'studentnummer',
];

$student = new Student;
foreach ($apiResult as $key => $value) {
    if (isset($map[$key])) {
        $student->{$map[$key]} = $value;
    }
}

print_r($student);

[incaz]

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
Zeker tegenwoordig waar er steeds meer data bij komt, en het niet altijd hoeft te zijn dat een object alles bevat. Een studentmummer hoeft bijvoorbeeld nog niet zijn toegekend (toegeven dat dit niet wenselijk is), we weten nog niet alles over een student, etc. Moet je dan voor elk veld dit weer toevoegen aan de repository?

Ik zou het gebruik altijd voorop stellen. In mijn ervaring gaat het gebruik meestal om vrij duidelijk omschreven dingen: de eigenschappen hebben betekenis. Die betekenis zou ik zo veel mogelijk expliciet vastleggen, om te voorkomen dat dat uit elkaar gaat lopen. Het gaat bijvoorbeeld helemaal mis als er termen als 'studentnummer' 'studentnr' en 'studentid' door elkaar gebruikt gaan worden.
Het gebruiken van een expliciete class-definitie maakt dat je binnen je applicatie weet dat het altijd $student->getId() is en nooit iets anders. Moet je dan op een of andere manier aansluiten op andere termen, dan hoef je dat maar op 1 plek vast te leggen, daar waar je de connectie maakt. Dus heeft Blackboard andere ideeen over de terminologie dan je eigen db? Prima, geen probleem - dat regel je in je mapping, op 1 enkele plek, en nergens anders dan daar hoef je er rekening mee te houden.

Tegelijkertijd snap ik wel wat je zegt: het kan prima dat diverse databronnen data aanbieden via hun API waar (nog) niets mee gebeurt. Die kun je dan inderdaad zolang zonder structuur opslaan. Zodra je er echter gebruik van gaat maken, en het dus betekenis krijgt binnen je applicatie, verdient het een heldere centrale eenduidige definitie, zodat als de API-aanbieder de naamgeving ooit gaat veranderen (en dat gaan ze doen, geheid), je geen runtime errors krijgt (of in stilte falende zaken die je helemaal niet opmerkt), en dat je niet op 30 plekken de keys moet aan gaan passen, maar je dat allemaal op 1 centrale plek hebt.

(Even los van OO, een andere kant hiervan is trouwens dat het wettelijk in principe niet is toegestaan is om persoonsgegevens op te slaan als je die niet gebruikt. Maar bij bv producteigenschappen is dat niet aan de orde en gaat het verhaal wel op.)

[Verwijderd]

Ik heb mijn code nu uitgebreid met de mogelijkheid voor de admin om een product toe te voegen.
Nu kwam meteen een vraag in mij op: Is het gebruikelijk om voor het admin gedeelte en de voorkant dezelfde class bestanden te gebruiken, of om aparte te gebruiken voor beide gedeeltes? (lijkt mij i.i.g. beter apart)

PHP:

<?php
class Product
{
    public $productName;
    public $productDescription;
    public $unitPrice;
    public $discount;
    
    public function getProductName()
    {
        return htmlspecialchars($this->productName);
    }
    public function getPriceWithDiscount()
    {
        return $this->unitPrice - ($this->discount / 100);
    }
}

abstract class BaseRepository
{
    private $_db;
    protected $classname;
    
    public function __construct(PDO $db)
    {
        $this->_db = $db;
    }
    
    public function fetch($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetch();
    }
    public function fetchAll($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result->execute($parameters);
        
        return $result->fetchAll();
    }
    public function insert($query, $parameters = []){
        $result = $this->_db->prepare($query);
        $result->setFetchMode(PDO::FETCH_CLASS, $this->classname);
        $result = $result->execute($parameters);
        
        if($result){
            return true;
        }
        else{
            return false;
        }
    }
}
class ProductRepository extends BaseRepository
{
    protected $classname = 'Product';
    
    public function getAllProducts()
    {
        return $this->fetchAll("SELECT productName, productDescription, unitPrice, discount FROM product");
    }
    
    public function getAllProductByCategory($category)
    {
        return $this->fetchAll("    
                                    SELECT * 
                                    FROM product AS p
                                    INNER JOIN product_category AS pc ON p.ID=pc.product_ID
                                    WHERE pc.category_ID = :category
        ", [':category' => $category]);
    }
    
    public function getProductById($id)
    {
        return $this->fetch("SELECT productName, productDescription, unitPrice, discount FROM product WHERE ID = :id", [':id' => $id]);
    }
    
    public function newProduct($productName, $productDescription, $unitPrice, $discount)
    {
        if($unitPrice > 0 && $discount > 0){
            return $this->insert("INSERT INTO product (ID, productName, productDescription, unitPrice, discount)
            VALUES ('', :productName, :productDescription, :unitPrice, :discount)", 
            [':productName' => $productName, ':productDescription' => $productDescription, ':unitPrice' => $unitPrice, ':discount' => $discount]);
        }
        else{
            return false;
        }
    }
}


try{
    $pdo = new PDO('mysql:host=localhost;dbname=webshop;port=pass', 'user', 'pass');
    $productRepository = new ProductRepository($pdo);
    $newProduct = $productRepository->newProduct('test', 'test', 1, 1);
    // Deze waarden worden vervangen door $_POST, maar dat formulier is er nog niet

    if(!$newProduct){
        echo 'Product is niet toegevoegd!';
    }
    
    $products = $productRepository->getAllProducts();
    
    if($products){
        foreach($products as $product)
        {
            echo $product->productName;
        }
    }
    else{
        echo 'Producten konden niet owrden opgehaald!';
    }
    
    unset($pdo);
}
catch(PDOException $err){
    echo 'Er is iets fout gegaan!'.$err;
}

[Bee.nl]

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
Wat is precies fout met een array gebruiken? Snap het punt van IDE's, maar waarom zou het niet mogen? Zeker tegenwoordig waar er steeds meer data bij komt, en het niet altijd hoeft te zijn dat een object alles bevat. Een studentmummer hoeft bijvoorbeeld nog niet zijn toegekend (toegeven dat dit niet wenselijk is), we weten nog niet alles over een student, etc. Moet je dan voor elk veld dit weer toevoegen aan de repository? 'Vroeger' had je nog beeld, maar steeds vaker komt er data bij/vallen stukjes weg, en gaan we naar steeds meer 'flexibele data'. Wat doe je als je van meerdere API's toch data wilt opslaan?
Het is toch goed mogelijk om data op te slaan als bijvoorbeeld JSON (zie NoSQL) en dit van (flexibele) keys te voorzien?

Niet om betweterig over te komem, maar zou het graag willen weten.

Ter aanvulling op de prima uitleg van Barryvdh en incaz:

Dergelijke flexibiliteit en dynamische data (of 'magic' zoals ik het wel eens noem), werkt in het begin leuk en aardig. Echter, wanneer je applicatie groter begin te worden gaat dit steeds meer tegen je werken (kan ik uit ervaring vertellen). Je verliest grip op de properties, het tracken van usages wordt lastiger en het debuggen wordt steeds moeizamer.

Daarnaast is het met arrays de vraag of 1) de index bestaat en 2) wat de value type is. Met objecten heb je garantie dat de property/getter/setter bestaat en mbv phpdoc weet je meteen wat de argument/return types zijn. Dat helpt rare (cast) bugs en silent errors te voorkomen. Ergo, probeer altijd zo expliciet en strict mogelijk te programmeren, tenzij een edge case anders vereist.

Het is overigens geen probleem om je de data voor het einddoel (template, api, etc) te converteren naar een array, zolang je in de voorafgaande business logic maar werkt met de (OO) modellen.

[ThomasG]

Bee.nl schreef op vrijdag 11 november 2016 @ 18:52:
[...]

Ter aanvulling op de prima uitleg van Barryvdh en incaz:

Dergelijke flexibiliteit en dynamische data (of 'magic' zoals ik het wel eens noem), werkt in het begin leuk en aardig. Echter, wanneer je applicatie groter begin te worden gaat dit steeds meer tegen je werken (kan ik uit ervaring vertellen). Je verliest grip op de properties, het tracken van usages wordt lastiger en het debuggen wordt steeds moeizamer.

Daarnaast is het met arrays de vraag of 1) de index bestaat en 2) wat de value type is. Met objecten heb je garantie dat de property/getter/setter bestaat en mbv phpdoc weet je meteen wat de argument/return types zijn. Dat helpt rare (cast) bugs en silent errors te voorkomen. Ergo, probeer altijd zo expliciet en strict mogelijk te programmeren, tenzij een edge case anders vereist.

Het is overigens geen probleem om je de data voor het einddoel (template, api, etc) te converteren naar een array, zolang je in de voorafgaande business logic maar werkt met de (OO) modellen.

Een beetje moderne PHP IDE kan anders prima met dynamische data omgaan. Steker nog, phpDoc bied daar functionaliteit voor.

[4Real]

Verwijderd schreef op donderdag 10 november 2016 @ 23:53:
[...]


Dat klopt! Bedankt.
Ben alleen benieuwd hoe je de rowCount function van PDO nu het beste kan gebruiken.

Niet, je getAll functie geeft een array terug (of gooit een Exception). Maar met die array kun je verder werken. De count functie kun je gebruiken om te kijken of je uberhaupt resultaten hebt gekregen.

Verwijderd schreef op vrijdag 11 november 2016 @ 15:54:
Ik heb mijn code nu uitgebreid met de mogelijkheid voor de admin om een product toe te voegen.
Nu kwam meteen een vraag in mij op: Is het gebruikelijk om voor het admin gedeelte en de voorkant dezelfde class bestanden te gebruiken, of om aparte te gebruiken voor beide gedeeltes? (lijkt mij i.i.g. beter apart)

Je DataRepository heeft geen kennis van gebruikers of andere logica. Dit komt allemaal in je controller / business layer. Het enige wat de DataRepository doet is data uit de database omhalen, omzetten naar een entiteit class en teruggeven. Daarnaast kun je ook commando's (insert/update/delete) naar de database sturen. Tevens klinkt het als dat je dubbel werk gaat doen en dat is al en big no-no!

Daarnaast nog wat andere punten

Je product variabelen zijn public, maar je hebt ook weer een get wrapper voor één van de variabelen. Wees consitent, ga voor get/set wrappers (en verberg de variabelen middels protected of private), of houdt ze allemaal public.

[Je hebt veel getProductXXXXX als je in de product class zit of product repository zit dan is het al logisch wat je scope is. Product, dus het voegt niet meer toe. Doe gewoon hetvolgende:

PHP:

<?php

$product->getName();
$product->setName('naam van het product');

$productRepository->getByID();
$productRepository->getAll();

Zorg voor consitentie door in de BaseRepository abstract functies op te nemen voor handelingen welke sowieso gaan voorkomen.

PHP:

abstract class BaseRepository
{
    abstract public function getAll();
    abstract public function getByID();
}

En een functie geeft altijd één type terug. Ondanks dat het in PHP kan is het alvast netjes om aan te leren dat een functie één type of null terug geeft. Daarnaast kan hij altijd een Exception gooien.
Dus als je getByID functie null terug geeft dan heeft hij geen resultaat kunnen vinden. getAll kan een lege array teruggeven, dat is opzich een goede keuze.
Newproduct zou ik anders doen, ik zou de functie omschrijven naar Save($entity); en hem daar laten uitzoeken of het een nieuw record is of al een bestaande.

Dan kun je ook het volgende doen:

PHP:

$product = new Product();
$product->setName('test');
// nog wat attributen setten

$productRepository->Save($product);

Je kan onderwater een attribuut meenemen welke aangeeft of het een nieuw record of bestaand is. Of in de productRepository een lijst met bestaande producten (hash van een class) zie: http://php.net/manual/en/function.spl-object-hash.php . Als de hash van het product niet in de tabel voorkomt dan is hij nieuw en kun je een insert query schrijven, anders een update query.

Zodoende hoef je na een tijdje geen queries te schrijven. Als je de class hebt gedefinieerd dan doet de repository de rest van het werk wel voor je.

[Barryvdh]

ThomasG schreef op vrijdag 11 november 2016 @ 19:04:
[...]
Een beetje moderne PHP IDE kan anders prima met dynamische data omgaan. Steker nog, phpDoc bied daar functionaliteit voor.

Als je een object maakt met magic properties ja, maar je kan niet een plain array phpdocs geven (waar het in dit geval dus over ging)

[ThomasG]

Barryvdh schreef op vrijdag 11 november 2016 @ 19:20:
[...]

Als je een object maakt met magic properties ja, maar je kan niet een plain array phpdocs geven (waar het in dit geval dus over ging)

Die je dus eenvoudig kunt mappen naar properties, waardoor je ook relaties eenvoudig kunt regelen. En meer mogelijkheden met je attributen.

[Barryvdh]

ThomasG schreef op vrijdag 11 november 2016 @ 19:22:
[...]
Die je dus eenvoudig kunt mappen naar properties, waardoor je ook relaties eenvoudig kunt regelen. En meer mogelijkheden met je attributen.

Dat is exact wat wij ook zeggen dus, mooi dat we het daar over eens zijn

[ThomasG]

Barryvdh schreef op vrijdag 11 november 2016 @ 19:33:
[...]

Dat is exact wat wij ook zeggen dus, mooi dat we het daar over eens zijn

Volgens mij werd hier juist gezegd dat je moet getters en setters, in de zin van $person->getFirstName() ed. aanmaken. En dat is gewoon niet zo. Je kunt dat prima dat prima dynamisch met $person->firstName regelen, aan de hand van __get en __set.

[Bee.nl]

ThomasG schreef op vrijdag 11 november 2016 @ 19:22:
[...]
Die je dus eenvoudig kunt mappen naar properties, waardoor je ook relaties eenvoudig kunt regelen. En meer mogelijkheden met je attributen.

Dat je ze kunt mappen naar properties begrijp ik, maar het ging me inderdaad om het werken met plain arrays. Het gebruik van arrays aan de input kant (array => object mapper) of aan de output kant (object als array weergeven) is niet meer dan logisch gebruik. Alles wat daartussen zit (business logic) zou idealiter via objecten lopen.

[4Real]

ThomasG schreef op vrijdag 11 november 2016 @ 19:38:
[...]
Volgens mij werd hier juist gezegd dat je moet getters en setters, in de zin van $person->getFirstName() ed. aanmaken. En dat is gewoon niet zo. Je kunt dat prima dat prima dynamisch met $person->firstName regelen, aan de hand van __get en __set.

Thuis maak ik daar ook gebruik van, maar meer omdat ik er nog een laag tussen zit. Via comments voeg ik extra info toe aan de variabel, bijvoorbeeld:

PHP:

class Person extends Object
{
  /**
   * @var string
   * @field FirstName
  **/
  protected $_FirstName;
}

Via via regelt ObjectManager het setten en getten van waardes. Zo kan ik ook types checken int krijgt string? ArgumentException! Door @readonly toe te voegen kan ik het attribuut alleen lezen maken.
Overhead ja, maar wel super cool

[ThomasG]

4Real schreef op vrijdag 11 november 2016 @ 19:45:
[...]

Thuis maak ik daar ook gebruik van, maar meer omdat ik er nog een laag tussen zit. Via comments voeg ik extra info toe aan de variabel, bijvoorbeeld:

PHP:

class Person extends Object
{
  /**
   * @var string
   * @field FirstName
  **/
  protected $_FirstName;
}

Via via regelt ObjectManager het setten en getten van waardes. Zo kan ik ook types checken int krijgt string? ArgumentException! Door @readonly toe te voegen kan ik het attribuut alleen lezen maken.
Overhead ja, maar wel super cool

Hiervoor zijn juist de @property, @property-read en @property-write tags. Zodat je iets krijgt als:

PHP:

/**
 * @property string $firstName
 * @property DateTime $birthdate
 * @property-read int $age
 */
class Person extends Model {
    // ...
}

Wat bijvoorbeeld prima werkt in combinatie met Laravel. En met een goede editor, werken zaken als auto complete, refactoring ed. zonder probleemn.

[Bee.nl]

ThomasG schreef op vrijdag 11 november 2016 @ 19:38:
[...]
Volgens mij werd hier juist gezegd dat je moet getters en setters, in de zin van $person->getFirstName() ed. aanmaken. En dat is gewoon niet zo. Je kunt dat prima dat prima dynamisch met $person->firstName regelen, aan de hand van __get en __set.

Ik zit dagelijks in phpstorm met magic (legacy) code te stoeien en uit ervaring kan ik vertellen dat dit in grotere applicaties makkelijk tot (onnodige) issues kan leiden. Daarom wil ik graag benadrukken dit zo veel mogelijk te mijden tenzij dit noodzakelijk is voor een specifieke casus.

• Usages tracken wordt bemoeilijkt. Een IDE als phpstorm kan veel, maar dynamic properties resolven is relatief beperkt.
• Een expliciete setter kan type hints bevatten om te voorkomen dat het verkeerde type in de methode belandt. Het is niet tof wanneer een fout pas tig niveaus dieper in de stack trace een fatal oplevert. Denk aan het meegeven van een scalar terwijl het een array moest zijn. In het slechtste geval vindt er verderop ook nog een implicit cast plaats (object naar string bijv). In php7 kan dit nog stricter door de toevoeging van scalar argument type hints en return type hints.
• Expliciete getters/setters kun je phpdoc geven, wat de kans op fouten kleiner maakt doordat je meer informatie krijgt over de types, het gebruik en eventuele exceptions. Ik weet van het bestaan van @property af, maar het is beperkter dan een compleet docblock.
• In een IDE kun je meteen doorklikken op de methode, zodat je gelijk de juiste plek bent.
• Expliciete getter/setters bevordert single responsibility. Stel dat er ergens validatie benodigd is zou je bij magic getter/setters een soort if/else of switch moeten bouwen om bepaalde properties af te vangen.
• Het uit elkaar houden van de getter en setter is iets lastiger als je usages van magic properties gaat zoeken.
• De performance van magic methods ligt iets lager (20% op mn php5.5 bak). Het kán een rol spelen wanneer er heel veel properties opgevraagd worden.
• Een goede IDE kan automatisch getters/setters genereren. Dus extra werk zou ook geen argument mogen zijn.

[Barryvdh]

ThomasG schreef op vrijdag 11 november 2016 @ 19:38:
[...]
Volgens mij werd hier juist gezegd dat je moet getters en setters, in de zin van $person->getFirstName() ed. aanmaken. En dat is gewoon niet zo. Je kunt dat prima dat prima dynamisch met $person->firstName regelen, aan de hand van __get en __set.

Ah, nee mijn reactie was gericht over deze vraag:

HollowGamer schreef op vrijdag 11 november 2016 @ 00:26:
Wat is precies fout met een array gebruiken? Snap het punt van IDE's, maar waarom zou het niet mogen? Zeker tegenwoordig waar er steeds meer data bij komt, en het niet altijd hoeft te zijn dat een object alles bevat. [..]

Ik ben er zelf ook een voorstand voor om gewoon dynamisch properties aan te roepen, in plaats van overal getter/setters te schrijven, maar dat is ook een kwestie van persoonlijke voorkeur. Daarop inhakend:

4Real schreef op vrijdag 11 november 2016 @ 19:18:
[..]

Je product variabelen zijn public, maar je hebt ook weer een get wrapper voor één van de variabelen. Wees consitent, ga voor get/set wrappers (en verberg de variabelen middels protected of private), of houdt ze allemaal public.
[..]

Ben ik het opzich ook mee eens, maar in dit voorbeeld geeft hij juist niet de onderliggende data terug, maar een aangepast. Nu is het voorbeeld van htmlentities juist niet zo handig, omdat dit iets wat je eigenlijk in je presentatie laag stopt, niet in je model. Maar bijv. een berekende prijs met korting, is wel iets wat hier goed kan. Wat mij betreft is het dan vaak leesbaar om hier een functie van te maken, zodat je ook ziet dat het niet zomaar de platte data is uit de database.

Ik ben wat dat betreft wel fan van de werkwijze van Laravel/Eloquent (Active Record style), heeeeeel versimpeld zoiets als hieronder. Maar zoals Bee.nl al zegt, dat is wel lastiger om terug te zoeken.

PHP:

<?php

class Model
{
    protected $attributes;

    public function __construct(array $attributes)
    {
        $this->attributes = $attributes;
    }
    
    public function __get($name)
    {
        if (method_exists($this, 'get'.ucfirst($name).'Attribute')) {
            return $this->{'get'.ucfirst($name).'Attribute'}();
        }

        if (isset($this->attributes[$name])) {
            return $this->attributes[$name];
        }
    }

    public function __set($name, $value)
    {
        $this->attributes[$name] = $value;
    }
}

/**
 * @property $firstname;
 * @property $lastname;
 * @property-read $fullname;
 */
class Student extends Model
{
    public function getFullnameAttribute()
    {
        return $this->attributes['firstname'] . ' '  . $this->attributes['lastname'];
    }
}

$student = new Student([
    'firstname' => 'Berry',
    'lastname' => 'vd. H',
]);

$student->firstname = 'Barry';

var_dump($student->firstname);
var_dump($student->fullname);

phpdocs kan je natuurlijk ook gewoon laten genereren op basis van je database en als je maar duidelijke conventies afspreekt hoeft het ook geen probleem te zijn om dat terug te zoeken.

[ Voor 8% gewijzigd door Barryvdh op 11-11-2016 20:31 ]

[Cartman!]

Ik ben ook duidelijk meer voorstander van expliciete getters/setters, die functies kan een goede IDE direct voor je maken en je zal nooit properties aanroepen die er niet zijn en verschilt imo niet veel van het gebruik van arrays meer dan. Het is net even wat stricter en daar hou ik van, magic methods probeer ik ten alle tijde te vermijden.

[Verwijderd]

Ik lees veel terug over Laravel, en heb zelf ook even op het internet gekeken.
Maar is het voor een zeer simpele webshop of website wel handig om zo'n heel framework erbij te pakken?

[Barryvdh]

Verwijderd schreef op vrijdag 11 november 2016 @ 22:25:
Ik lees veel terug over Laravel, en heb zelf ook even op het internet gekeken.
Maar is het voor een zeer simpele webshop of website wel handig om zo'n heel framework erbij te pakken?

Ik gebruik het de afgelopen 4 jaar voor elk maatwerk project, maar het ligt eraan hoe 'simpel' je website echt is.

In mijn ervaring begint alles heel simpel en blijf je het vaak uitbouwen, totdat je eigenlijk grote delen aan het namaken bent. Laravel bevat gewoon veel zaken out-of-the-box die het makkelijk maken. En waarschijnlijk denk je die nu niet eens nodig te hebben.

Nu is het leuk om zelf je database classes te schrijven, maar dat wordt gewoon steeds complexer. Een voorbeeldje wat je nu hebt, is bijna zonder custom code te schrijven, op basis van 2 simpele Models:

PHP:

<?php

class Product extends Illuminate\Database\Eloquent\Model
{
    public function getPriceWithDiscountAttribute()
    {
        return $this->attributes['unit_price'] - ($this->attributes['discount'] / 100);
    }

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

class Category extends Illuminate\Database\Eloquent\Model
{
    public function products()
    {
        return $this->hasMany(Product::class);
    }
}

// Create project from array
$product = Product::create([
    'name' => 'test',
    'description' => 'Test',
    'unit_price' => 6.84,
    'discount' => 5,
]);

if (!$product->exists){
    echo 'Product is niet toegevoegd!';
}

// Get all products
$products = Product::all();

if ($products->count() > 0) {
    foreach ($products as $product) {
        echo $product->name .': ' . $product->price_with_discount;
        if ($product->category) {
            echo $product->category->title;
        }
    }
} else {
    echo 'Geen producten gevonden';
}

// Find by id, update attribute
$product = Product::find(3);
$product->name = 'New name';
$product->save();

// Or delete
$product->delete();

// Use query builder
$foodProducts = Product::where('unit_price', '>', 10)->orderBy('name')->paginate(50);

$category = Category::find(2);
foreach ($category->products as $product) {
    echo $product->name;
}

En je gaat gegarandeerd tegen dingen aanlopen als routing (nette urls, hoe krijg je die parameters netjes naar de goede controller), templating (hoe hou je presentatie overzichtelijk en escape je output goed), authenticatie (inloggen etc), caching, notificaties, background taken (queues), cli commando's, verschillende configuraties, validaties, etc etc. Lees maar gewoon een keer de docs door als je je verveelt https://laravel.com/docs/5.3/

[Verwijderd]

Barryvdh schreef op vrijdag 11 november 2016 @ 22:52:
[...]

Ik gebruik het de afgelopen 4 jaar voor elk maatwerk project, maar het ligt eraan hoe 'simpel' je website echt is.

In mijn ervaring begint alles heel simpel en blijf je het vaak uitbouwen, totdat je eigenlijk grote delen aan het namaken bent. Laravel bevat gewoon veel zaken out-of-the-box die het makkelijk maken. En waarschijnlijk denk je die nu niet eens nodig te hebben.

Nu is het leuk om zelf je database classes te schrijven, maar dat wordt gewoon steeds complexer. Een voorbeeldje wat je nu hebt, is bijna zonder custom code te schrijven, op basis van 2 simpele Models:

PHP:

<?php

class Product extends Illuminate\Database\Eloquent\Model
{
    public function getPriceWithDiscountAttribute()
    {
        return $this->attributes['unit_price'] - ($this->attributes['discount'] / 100);
    }

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

class Category extends Illuminate\Database\Eloquent\Model
{
    public function products()
    {
        return $this->hasMany(Product::class);
    }
}

// Create project from array
$product = Product::create([
    'name' => 'test',
    'description' => 'Test',
    'unit_price' => 6.84,
    'discount' => 5,
]);

if (!$product->exists){
    echo 'Product is niet toegevoegd!';
}

// Get all products
$products = Product::all();

if ($products->count() > 0) {
    foreach ($products as $product) {
        echo $product->name .': ' . $product->price_with_discount;
        if ($product->category) {
            echo $product->category->title;
        }
    }
} else {
    echo 'Geen producten gevonden';
}

// Find by id, update attribute
$product = Product::find(3);
$product->name = 'New name';
$product->save();

// Or delete
$product->delete();

// Use query builder
$foodProducts = Product::where('unit_price', '>', 10)->orderBy('name')->paginate(50);

$category = Category::find(2);
foreach ($category->products as $product) {
    echo $product->name;
}

En je gaat gegarandeerd tegen dingen aanlopen als routing (nette urls, hoe krijg je die parameters netjes naar de goede controller), templating (hoe hou je presentatie overzichtelijk en escape je output goed), authenticatie (inloggen etc), caching, notificaties, background taken (queues), cli commando's, verschillende configuraties, validaties, etc etc. Lees maar gewoon een keer de docs door als je je verveelt https://laravel.com/docs/5.3/

Bedankt voor je reactie!
Ik heb het geïnstalleerd, en even gekeken in de documentatie.
Ik ben niet overtuigd dat dit mij helpt in ontwikkeling. < In tegenstelling tot dit ziet het er wel interessant uit. Maar hoe zit het met de snelheid? Wordt die erg (negatief) beïnvloed door Laravel?
Toch ben ik nog niet heel erg overtuigd, omdat ik wel afhankelijk ben van andere code nu. Wat als er een grote update is, werken dan mijn apps oppeens niet meer?

[ Voor 5% gewijzigd door Verwijderd op 12-11-2016 01:19 ]

[Barryvdh]

Verwijderd schreef op zaterdag 12 november 2016 @ 00:38:
[...]


Bedankt voor je reactie!
Ik heb het geïnstalleerd, en even gekeken in de documentatie.
Ik ben niet overtuigd dat dit mij helpt in ontwikkeling. < In tegenstelling tot dit ziet het er wel interessant uit. Maar hoe zit het met de snelheid? Wordt die erg (negatief) beïnvloed door Laravel?
Toch ben ik nog niet heel erg overtuigd, omdat ik wel afhankelijk ben van andere code nu. Wat als er een grote update is, werken dan mijn apps oppeens niet meer?

Meer code die meer doet is langere laad tijd ja. Qua boilerplate code is het trager dan plat php, alleen kan zich dit weer terug winnen door dingen als queues, cache en eager loading. Maar voor simpele dingen kan het langzamer zijn.

Al is het dus niet alleen snelheid, maar ook snelheid van ontwikkeling en veiligheid.

Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

[Verwijderd]

Barryvdh schreef op zaterdag 12 november 2016 @ 07:25:
[...]

Meer code die meer doet is langere laad tijd ja. Qua boilerplate code is het trager dan plat php, alleen kan zich dit weer terug winnen door dingen als queues, cache en eager loading. Maar voor simpele dingen kan het langzamer zijn.

Al is het dus niet alleen snelheid, maar ook snelheid van ontwikkeling en veiligheid.

Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

Bedankt voor je reactie Barry!
Voorlopig blijf ik nog even alles zelf schrijven, en ga ondertussen bezig met het verkennen van laravel en uitproberen!

[Cartman!]

Er zijn natuurlijk veel meer frameworks dan Laravel; Symfony (mijn favoriet maar wellicht meer gericht op high end en enterprise dan andere frameworks), Silex, Lumen, Phalcon... ga de boel rustig verkennen en kies wat bij je past. Coden zonder frameworks of libraries is anno 2016 imo ondenkbaar, als je zelf iets gaat maken ga je alle fouten maken die anderen allang voor je hebben opgelost. Je levert wat in op snelheid van uitvoer van code maar het ontwikkelen is zoveel sneller en onderhoud zoveel makkelijker.

Barryvdh schreef op zaterdag 12 november 2016 @ 07:25:
Code gaat niet 'ineens' kapot. Laravel heeft releases van 5.3.x bijv, waarbij die reeks compatibele is. Bij 5.4 is er meestal wat breaking changes. Maar je bent niet verplicht te updaten natuurlijk, dat doe je zelf handmatig met Composer.

Licht offtopic misschien maar hier moet je wel enorm opletten, standaard volgen packages altijd semver waarbij 5.4 backwards compatible hoort te zijn met 5.3. Laravel houdt zich hier blijkbaar niet als je 5.3 niet veilig kunt updaten naar 5.4 aan dus moet je het goed vastzetten op 5.3.x ipv 5.x.

[ Voor 87% gewijzigd door Cartman! op 13-11-2016 20:23 ]

[Barryvdh]

Cartman! schreef op zondag 13 november 2016 @ 19:18:
Licht offtopic misschien maar hier moet je wel enorm opletten, standaard volgen packages altijd semver waarbij 5.4 backwards compatible hoort te zijn met 5.3. Laravel houdt zich hier blijkbaar niet als je 5.3 niet veilig kunt updaten naar 5.4 aan dus moet je het goed vastzetten op 5.3.x ipv 5.x.

Klopt, maar in principe staat dat standaard ook gewoon zo ingesteld in je composer.json als je de applicatie cloned of installeert met composer create-project of de laravel installer.
Het is inderdaad wel anders dan de meeste ki ratjes (is dan ook geen library maar framework)
Heeft wel als voordeel dat Taylor iets meer vrijheid heeft om dingen te veranderen om te sneller te verbeteren.

[Cartman!]

Barryvdh schreef op zondag 13 november 2016 @ 21:23:
Heeft wel als voordeel dat Taylor iets meer vrijheid heeft om dingen te veranderen om te sneller te verbeteren.

offtopic:
Wat mij betreft misschien wel het grootste nadeel van Laravel: een 1 man show van een gast die niet goed met kritiek kan omgaan maar dan gaan we wel n beetje off topic

Overigens staat semver los van snel dingen kunnen verbeteren natuurlijk, je kan dat ook backwards compatible doorvoeren.

[ Voor 19% gewijzigd door Cartman! op 13-11-2016 21:40 ]

[Barryvdh]

Cartman! schreef op zondag 13 november 2016 @ 21:27:
[...]

offtopic:
Wat mij betreft misschien wel het grootste nadeel van Laravel: een 1 man show van een gast die niet goed met kritiek kan omgaan maar dan gaan we wel n beetje off topic

Overigens staat semver los van snel dingen kunnen verbeteren natuurlijk, je kan dat ook backwards compatible doorvoeren.

Klopt, daar is grote Laravel topic voor en volgens mij hebben we daar die discussie al paar keer gevoerd

On topic, ik ben er zelf ook voorstander voor om libraries te gebruiken wanneer mogelijk voor productie, maar ook om het zelf te doen om te leren (of als je denkt dat het beter kan). Maar van frameworks en libraries kan je ook veel leren natuurlijk.

[Verwijderd]

Cartman! schreef op zondag 13 november 2016 @ 19:18:
Coden zonder frameworks of libraries is anno 2016 imo ondenkbaar, als je zelf iets gaat maken ga je alle fouten maken die anderen allang voor je hebben opgelost.

Dat is natuurlijk niet waar, je kan nog steeds goede webapplicaties ontwikkelen zonder het gebruik van een framework of librarie, hoeveel ontwikkelaars doen dat wel niet. Fouten maken hoeft niet persé als je goed ontwikkeld, al is het natuurlijk wel waar dat de meeste fouten in een framework opgelost zijn.

Bedankt voor je tip, ik ga zeker ook andere frameworks proberen

[ Voor 21% gewijzigd door Verwijderd op 13-11-2016 22:46 ]

[Cartman!]

Verwijderd schreef op zondag 13 november 2016 @ 22:43:
[...]
Dat is natuurlijk niet waar, je kan nog steeds goede webapplicaties ontwikkelen zonder het gebruik van een framework of librarie, hoeveel ontwikkelaars doen dat wel niet.

Professionele: ik gok 0... Niet-professioneel: vast een hoop.

Fouten maken hoeft niet persé als je goed ontwikkeld, al is het natuurlijk wel waar dat de meeste fouten in een framework opgelost zijn.

Ik acht de kans dat je zonder framework fouten maakt zo'n 99,99%. Denk aan zaken als SQL Injection, XSS en CSRF qua security maar ook aan simpelweg onderhoud en het up to date kunnen houden van al je projecten. Stel jij vindt een bug in een stukje code, ga je die met de hand doorvoeren in al je vorige projecten en uitrollen? Met bestaande libraries worden zowel de (meeste) bugs voor je gespot, gefixt en beschikbaar gesteld middels een "composer update vendor/package" command en klaar ben je.

Bedankt voor je tip, ik ga zeker ook andere frameworks proberen

Er zijn een hoop voors en tegens oor diverse frameworks, gebruiken waar jij t meest productiefst in bent is uiteindelijk het belangrijkst

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 09:45:

Professionele: ik gok 0...

Niet helemaal goed gegokt...

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 10:28:
[...]

Niet helemaal goed gegokt...

Ik neem aan dat jij dan op jezelf doelt dan? Kun je dit toelichten? Wat versta jij onder professioneel?

edit: Misschien had ik er "Ik hoop 0" van moeten maken.

[ Voor 10% gewijzigd door Cartman! op 14-11-2016 10:38 ]

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:32:
Ik neem aan dat jij dan op jezelf doelt dan? Kun je dit toelichten? Wat versta jij onder professioneel?

Ja, ik doel op mezelf - 30 jaar ontwikkelaar waarvan de laatste 13 als zelfstandig webdeveloper.

En toelichten? Ik gebruik geen framework. Ik heb zelf wel in de loop van de tijd een CMS opgebouwd dat ik meestal inzet, maar soms kan ik dat i.v.m. eisen omtrend intellectueel eigendom niet inzetten, en dan gaat het gewoon van scratch af aan.

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 10:40:
En toelichten? Ik gebruik geen framework. Ik heb zelf wel in de loop van de tijd een CMS opgebouwd dat ik meestal inzet, maar soms kan ik dat i.v.m. eisen omtrend intellectueel eigendom niet inzetten, en dan gaat het gewoon van scratch af aan.

Maar geen framework...ook geen libraries? Ik was er heilig van overtuigd dat PHP-developers toch ondertussen van het Not Invented Here-syndroom af waren. Ik ben oprecht verbaasd en kan hier totaal niet bij.

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:44:
Maar geen framework...ook geen libraries?

Een PDF-library of zoiets wel, maar niet vaak.

Ik ben oprecht verbaasd en kan hier totaal niet bij.

Kun je zo hebben, met meningen!

[Cartman!]

Met alle frameworks, libraries en tools (composer, phpunit, behat) die er tegenwoordig zijn zou je jezelf denk ik een hoop tijd kunnen besparen. Ik kan me geen type project voorstellen waarbij het niet zou lonen ieder geval. Heb je specifieke redenen om geen gebruik te maken van bestaande frameworks?

Ik vind het een interessant onderwerp, misschien maar eens vragen of we dit moeten afsplitsen - Inmiddels gedaan.

[ Voor 12% gewijzigd door Cartman! op 14-11-2016 11:08 ]

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 10:55:
Ik kan me geen type project voorstellen waarbij het niet zou lonen ieder geval.

Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.

Heb je specifieke redenen om geen gebruik te maken van bestaande frameworks?

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symphony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

En als ik iets nieuws nodig heb zoek ik een library op, of maak ik er zelf een in mijn vrije tijd.

[Ventieldopje]

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]

Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.


[...]

Zoals de onderdelen in Zend en Symfony die te herbruiken zijn bedoel je?

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symphony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

En als ik iets nieuws nodig heb zoek ik een library op, of maak ik er zelf een in mijn vrije tijd.

Je hoeft geen specialist te zijn om gebruik te maken van frameworks (of delen er van). Dit klinkt meer is "ik vind het wiel opnieuw uit omdat ik mijn eer hoog te houden heb"

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 12:49:
[...]
Och...de meeste webprojecten hebben dezelfde onderdelen nodig, dus als je dingen als databasetoegang, toegangsrechten, etcetera geregeld hebt, ofwel via het CMS of door hergebruik van een bestaande module, dan zijn de spannendste dingen wel gedekt.

En die onderdelen zijn allemaal voorzien van unit tests? Wel eens een security scan laten doen? Makkelijk te updaten als je een bug vindt? Goede documentatie?

Ik ben een (PHP-)programmeur, en dat wil ik blijven. Ik wil geen Symfony/Laravel/WordPress/whatever specialist zijn - dat zie ik als een beperking.

Je denkt dat je geen programmeur meer bent als je een framework gebruikt, waarom precies? Sinds ik frameworks ben gaan gebruiken (jaaaren geleden inmiddels) heb ik juist zo ontzettend veel geleerd ervan op gebied van OOP/schaalbaarheid/uitbreidbaarheid dat ik ervoor allemaal niet wist en in m'n eentje ook niet snel had uitgevonden. Niks houdt je tegen om meerdere frameworks te kunnen overigens.

Waarschijnlijk verschillen de soort (type/grootte) projecten die we doen ontzettend van elkaar maar zelfs voor simpele dingetjes pak ik altijd een framework, er zijn geen nadelen bij mij bekend. Je kan simpelweg direct van start en elk component wat je gebruikt kun je min of meer op vertrouwen dat het werkt.

Ik zou er niet aan moeten denken dat ik dingen als StackPHP, DBAL, Monolog en/of Twig zelf zou moeten gaan maken. Die tijd besteed ik liever aan het maken van de projecten zelf. Het is je goed recht overigens, daar niet van...ik ben vooral benieuwd naar de beweegredenen van alles zelf willen doen.

Interessant leesvoer over waarom een framework handig is: http://symfony.com/why-use-a-framework en dit is een heel mooie post die laat zien hoeveel zaken een framework voor je kan oplossen: http://symfony.com/doc/cu...flat_php_to_symfony2.html In beide gevallen is dit gericht op Symfony maar in feite geldt hetzelfde voor elk ander bekend framework (Silex, Laravel, Lumen, Yii, CodeIgniter).

[ Voor 10% gewijzigd door Cartman! op 14-11-2016 13:59 ]

[Bee.nl]

Cartman! schreef op maandag 14 november 2016 @ 13:45:
Je kan simpelweg direct van start en elk component wat je gebruikt kun je min of meer op vertrouwen dat het werkt.

Precies. Het scheelt zo veel tijd dat je niet zelf bezig hoeft te zijn met het uitvogelen van componenten. Als devver wil je immers zo veel mogelijk feature-gericht bezig zijn. Dus op 'hoger' niveau componenten combineren/configureren/uitbouwen in plaats van low-level alles moeten uitpluizen en debuggen, terwijl andere mensen dat al voor je gedaan hebben.

Je hoeft niet een compleet framework als Symfony/ZF te integreren, ze hebben alles in reusable components opgedeeld en je kunt zelf bepalen wat je gebruikt en wat niet. Console nodig? Hop, symfony/console in de composer.json en gaan met die features. Ik ben ook wel benieuwd naar de beweegredenen om bestaande packages niet te omarmen.

_{Waar blijft het afgesplitste topic}

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 09:45:


Ik acht de kans dat je zonder framework fouten maakt zo'n 99,99%. Denk aan zaken als SQL Injection, XSS en CSRF qua security maar ook aan simpelweg onderhoud en het up to date kunnen houden van al je projecten. Stel jij vindt een bug in een stukje code, ga je die met de hand doorvoeren in al je vorige projecten en uitrollen? Met bestaande libraries worden zowel de (meeste) bugs voor je gespot, gefixt en beschikbaar gesteld middels een "composer update vendor/package" command en klaar ben je.

SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

[Ventieldopje]

Verwijderd schreef op maandag 14 november 2016 @ 19:00:
[...]


SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

Nee, je kent toevallig programmeurs die werken aan projecten waarbij geen frameworks worden gebruikt. Als je als programmeur structureel de keuze maakt geen framework te gebruiken leent óf het project zich er niet voor (lijkt mij zeer zelden voorkomen, maar goed) óf vind je telkens het wiel opnieuw uit.

Overigens laten we duidelijk zijn, een eigen framework is ook een framework

[Verwijderd]

Ventieldopje schreef op maandag 14 november 2016 @ 19:11:
[...]


Nee, je kent toevallig programmeurs die werken aan projecten waarbij geen frameworks worden gebruikt. Als je als programmeur structureel de keuze maakt geen framework te gebruiken leent óf het project zich er niet voor (lijkt mij zeer zelden voorkomen, maar goed) óf vind je telkens het wiel opnieuw uit.

Overigens laten we duidelijk zijn, een eigen framework is ook een framework

Ah, ja uiteraard. Dan neem ik mijn woorden terug!
Want ze gebruiken wel eigen frameworks!

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 19:00:
SQL injections en XSS kan je zelf makkelijk tegen gaan. CSRF wordt een iets lastigere, maar dat is ook te doen.

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

Overigens ken ik genoeg professionele programmeurs die geen gebruik maken van frameworks

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen (en stellen ze t weer open source beschikbaar).

Ik ben echt benieuwd wat voor soort projecten er dus gemaakt worden door diegenen die jij kent en geen gebruik maken van frameworks.

Ventieldopje schreef op maandag 14 november 2016 @ 19:11:
Overigens laten we duidelijk zijn, een eigen framework is ook een framework

In absolute zin heb je gelijk maar ik acht de kans zeer klein dat die frameworks van hoge kwaliteit zijn dus of dat een verbetering is...ik denk dat het ontzettend tegenvalt.

[ Voor 18% gewijzigd door Cartman! op 14-11-2016 19:22 ]

[Ventieldopje]

Cartman! schreef op maandag 14 november 2016 @ 19:17:
[...]

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

[...]

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen.


[...]

In absolute zin heb je gelijk maar ik acht de kans zeer klein dat die frameworks van hoge kwaliteit zijn dus of dat een verbetering is...ik denk dat het ontzettend tegenvalt.

Tsja, maar dan zitten we in ieder geval weer op één lijn wat betreft frameworks. Een eigen framework is overigens ook niet per definitie 100% eigen code. Laravel is ook gewoon grotendeels Symfony

[Cartman!]

Ventieldopje schreef op maandag 14 november 2016 @ 19:22:
[...]
Tsja, maar dan zitten we in ieder geval weer op één lijn wat betreft frameworks. Een eigen framework is overigens ook niet per definitie 100% eigen code. Laravel is ook gewoon grotendeels Symfony

Daar heb je een punt maar dan bouw je je framework weer met library code (componenten, hoe je t noemt) en het gaat juist om frameworks maken zonder libraries omdat liever zelf het wiel wordt uitgevonden.

[Verwijderd]

Cartman! schreef op maandag 14 november 2016 @ 19:17:
[...]

Het kan allemaal als je goed genoeg bent maar waarom zou je al die tijd erin willen steken als anderen dat allang voor je opgelost hebben en getest en gebruikt hebben in productie?

[...]

Dan hebben we een verschil in interpretatie van wat professioneel is denk ik. Tenzij het developers zijn bij Facebook of Twitter die dusdanig in grote schaal moeten werken dat gewone frameworks niet voldoen. Maar zelfs daar maken ze eigen frameworks (denk aan bijvoorbeeld React) om dingen op te lossen en hebben ze daar de resources het echt goed door te testen en security scans te doen (en stellen ze t weer open source beschikbaar).

Ik ben echt benieuwd wat voor soort projecten er dus gemaakt worden door diegenen die jij kent en geen gebruik maken van frameworks.

Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

[Ventieldopje]

Cartman! schreef op maandag 14 november 2016 @ 19:25:
[...]

Daar heb je een punt maar dan bouw je je framework weer met library code (componenten, hoe je t noemt) en het gaat juist om frameworks maken zonder libraries omdat liever zelf het wiel wordt uitgevonden.

Dan ben ik bang dat je in 99% het wiel opnieuw uitvind. Niets mis mee mits om goeie redenen, ego of "professioneel" is er daar geen van.

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
[...]


Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Ehh, gefeliciteerd

[Cartman!]

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Wat voor soort webapplicaties dan en in welke talen wordt dat gemaakt? Ik kan me werkelijk waar niet voorstellen dat die lui allemaal t wiel opnieuw aan t uitvinden zijn. Aan de andere kant heb ik genoeg sollicitatiegesprekken gedaan met (hoger opgeleide) mensen die ook niet wisten wat bijv. XSS was en wat ze er tegen moesten doen...

Ventieldopje schreef op maandag 14 november 2016 @ 19:27:
Dan ben ik bang dat je in 99% het wiel opnieuw uitvind. Niets mis mee mits om goeie redenen, ego of "professioneel" is er daar geen van.

Zeker, daarom zou ik dit als developer ten alle tijden willen vermijden. Meestal wordt het wiel namelijk vierkant uitgevonden. Ik denk dat professionaliteit daar zeker een rol in speelt, ken je eigen beperkingen en ga zo spaarzaam mogelijk om met je tijd. Ik heb de zelfkennis dat ik niet een betere logger dan Monolog ga maken, of een betere template engine dan Twig (geen uitnodiging deze twee voorbeelden te bediscussieren ) en verwacht dat iedere developer dat heeft. Ik besteed die tijd liever aan het zo goed maken van m'n project voor de klant.

[Verwijderd]

Wauw... O.o

[Tjolk]

Cartman! schreef op maandag 14 november 2016 @ 19:37:

Zeker, daarom zou ik dit als developer ten alle tijden willen vermijden. Meestal wordt het wiel namelijk vierkant uitgevonden. Ik denk dat professionaliteit daar zeker een rol in speelt, ken je eigen beperkingen en ga zo spaarzaam mogelijk om met je tijd. Ik heb de zelfkennis dat ik niet een betere logger dan Monolog ga maken, of een betere template engine dan Twig (geen uitnodiging deze twee voorbeelden te bediscussieren ) en verwacht dat iedere developer dat heeft. Ik besteed die tijd liever aan het zo goed maken van m'n project voor de klant.

Op zich heb je gelijk, maar toch kan het zeker geen kwaad om zelf ook eens de moeite te nemen om een framework te bouwen. Gewoon voor jezelf en niet voor productie. Je leert daarmee toch een hoop zaken zelf te bekijken en zo weet je gewoon beter wat er allemaal gebeurd onder de motorkap.

[Cartman!]

Ger schreef op dinsdag 15 november 2016 @ 08:00:
Gewoon voor jezelf en niet voor productie.

Precies maar dan is het doel anders Overigens besteed ik m'n tijd liever aan nieuwe dingen maar dat is dan een persoonlijke keuze.

Verwijderd schreef op dinsdag 15 november 2016 @ 00:12:
Wauw... O.o

Ik ben nog steeds benieuwd naar je beweegredenen om alles zelf te willen doen.

[ Voor 52% gewijzigd door Cartman! op 15-11-2016 08:57 ]

[Hydra]

Verwijderd schreef op maandag 14 november 2016 @ 19:25:
Ik heb het over software engineers die informatica (wo- en hbo-niveau) gestudeerd hebben.
Het gaat over webapplicaties voor diverse grote ondernemingen.

Ik ken genoeg HBO-informatica 'ontwikkelaars' die bij dat soort shops werken en dat zijn m.i. geen van allen professionele developers.

Als je als developer niet inziet dat het in vrijwel alle situaties beter is om een ander zoveel mogelijk werk te laten doen ben je gewoon een prutser. Dit zijn de types die vinden dat ze prima zelf een SHA-1 based password hash kunnen bakken i.p.v. gewoon een standaard framework te gebruiken dat wel battle-tested is.

Cartman! schreef op dinsdag 15 november 2016 @ 08:50:
Ik ben nog steeds benieuwd naar je beweegredenen om alles zelf te willen doen.

Arrogantie. Niks meer. Niks minder. Een groot probleem onder developers die meestal alleen / in kleine teams werken.

[ Voor 21% gewijzigd door Hydra op 15-11-2016 09:34 ]

[ThomasG]

Hydra schreef op dinsdag 15 november 2016 @ 09:33:
[...]


Arrogantie. Niks meer. Niks minder. Een groot probleem onder developers die meestal alleen / in kleine teams werken.

Dat, en omdat er een hoop broodje aap verhalen de ronde doen. Een argument wat ik vaak gehoord heb, is dat zo'n framework traag is. Terwijl ze relatief snel zijn wanneer je ze niet constant in debug mode draait, en de caches hun werk laat doen.

[jbdeiman]

ThomasG schreef op dinsdag 15 november 2016 @ 10:00:
[...]
Dat, en omdat er een hoop broodje aap verhalen de ronde doen. Een argument wat ik vaak gehoord heb, is dat zo'n framework traag is. Terwijl ze relatief snel zijn wanneer je ze niet constant in debug mode draait, en de caches hun werk laat doen.

Dat is tegenwoordig wel waar, maar er zijn veel ontwikkelaars die al meer dan 5 jaar PHP ontwikkelen. De laatste jaren zijn er verschillende (en echt vollwassen) frameworks ontstaan maar als je dan al zelf een basis hebt geschreven waar je op voort kan borduren, waarom zou je dan opnieuw beginnen op basis van een Framwork, anders dan dat je tegen dusdanige problemen aanloopt, dat een herschrijf actie benodigd is?

Ik vind het persoonlijk te kort door de bocht om te stellen dat je niet professioneel bent als je geen framework gebruikt. Wel ben ik het ermee eens dat de voordelen van een framework veel meer waard zijn dan enkele nadelen.
Professionaliteit is voor mij te halen uit enkele zaken:
- De basis begrijpen/ kennen (dus ook weten wat er onder de motorkap gebeurt). D.w.z. niet blind alleen maar van een framework uitgaan maar ook een (gezonde!) nieuwsgierigheid naar hoe e.e.a. werkt, ipv het alleen maar te gebruiken.
- Een vertaling kunnen maken van gewenste functionaliteit naar te gebruiken stukken van een framework + bepalen hoe/ wat je aan gegevens nodig hebt om aan de functionaliteit te voldoen. Welke objecten met welke parameters/ velden zijn nodig en hoe ziet het datamodel eruit (dit kan ook op basis van je code gecreëerd worden)
- Weten waarom je bepaalde functionaliteiten wel of juist niet gebruikt, keuzes kunnen onderbouwen, dus niet "omdat iedereen het doet" of "omdat ik ervan uitga dat deze functionaliteit goed werkt of het framework dit vast perfect kan" zoals ik een paar keer terug denk te lezen in dit topic, maar ook snappen wat er dan gebeurt en waarom dit dan een goede optie is. Dit kan uiteraard door te proberen e.e.a. uit de code te halen, maar kan in veel gevallen ook op basis van ervaringen van anderen en documentatie over frameworks.

[Hydra]

jbdeiman schreef op dinsdag 15 november 2016 @ 10:22:
Dat is tegenwoordig wel waar, maar er zijn veel ontwikkelaars die al meer dan 5 jaar PHP ontwikkelen. De laatste jaren zijn er verschillende (en echt vollwassen) frameworks ontstaan maar als je dan al zelf een basis hebt geschreven waar je op voort kan borduren, waarom zou je dan opnieuw beginnen op basis van een Framwork, anders dan dat je tegen dusdanige problemen aanloopt, dat een herschrijf actie benodigd is?

Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.

Ik vind het persoonlijk te kort door de bocht om te stellen dat je niet professioneel bent als je geen framework gebruikt.

Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Professionaliteit is voor mij te halen uit enkele zaken:
- De basis begrijpen/ kennen (dus ook weten wat er onder de motorkap gebeurt).

Het gebruik van een framework sluit niet uit dat je de interne werking ervan goed kent. Ik heb zelf veel Spring kennis. Dat is onderdeel van m'n marketability zelf. Hoeveel bedrijven denk je dat geïnteresseerd zijn in mijn kennis van het home-grown Coldfusion framework waar ik in m'n vorige (korte) baan mee gewerkt heb? Dat is exact 1.

[ Voor 14% gewijzigd door Hydra op 15-11-2016 10:34 ]

[Barryvdh]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.


[...]


Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Al is het natuurlijk zo dat Laravel en Symfony in de eerste instantie ook gewoon 'interne frameworks' waren. En Laravel is grotendeels door 1 persoon geschreven (Taylor Otwell). Toen werd het natuurlijk wel populairder en meer mensen die meewerkten met pull requests ed. Dus dat had wel degelijk iets wat 'beter' (of iig anders) dan bestaande frameworks was.
Toegeven, hij gebruikte bijv. wel de HttpFoundation van Symfony, maar het Eloquent ORM en de Blade templating code zijn volgens mij gewoon vanaf scratch geschreven.
Ook alle andere componenten/libraries van alle frameworks zijn ooit ontstaan als alternatief voor bestaande code. Al is het in 99% niet zo dat nieuw == beter.

Maar ik heb zelf ook nog steeds een eigen CMS wat ik heel soms gebruikt. Is lang niet zo flexibel/uitgebreid als Laravel of Drupal/Wordpress, maar dat hoeft ook helemaal niet. Het is snel op te zetten voor bepaalde sites, snelle requests (doet bijna niks) en simpel. Het kan best zijn dat je intern in een bedrijf met je team gewoon een goed framework hebt wat gewoon werkt. Maar hoe meer ik met libraries/frameworks werk, hoe meer ik probeer bestaande onderdelen stapje voor stapje te vervangen (bijv eigen DB class -> Eloquent, templates -> Twig, router/http foundation erin etc.).


Grote voordeel van Laravel ed. is dat, als het een keer afwijkt van je standaard project, je niet alsnog alles zelf hoeft te doen. Er bestaat al gewoon zoveel, veel use cases zijn al voorbij gekomen en geïmplementeerd door anderen. Of iig rekening mee gehouden zodat je het alsnog zelf flexibel kan inbouwen.

[jbdeiman]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Omdat wat je zelf geschreven hebt hoogstwaarschijnlijk gewoon vrij bagger is t.o.v. wat er in de markt beschikbaar is. Het is arrogant te denken dat jij in je eentje iets neer kan zetten met iets in de buurt van de kwaliteit en flexibiliteit van een groot OS framework.

Je moet wel de tijd investeren om de boel opnieuw op te bouwen met een framework en je daarin te verdiepen. Soms kan dit gewoon niet uit, of is dit niet mogelijk doordat een baas/ manager zit te pushen. (nu kan je je afvragen of de manager dan een professional is, maar dat is een andere discussie.)

[...]

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
Wat is professionaliteit in jouw ogen? Je wordt betaald om goeie software op te leveren, niet om wielen opnieuw uit te vinden. Een eigen 'framework' schrijven en onderhouden kost op z'n minst tijd die je nuttiger kunt besteden. En in de worst case zitten er gewoon ernstige security bugs in.

Maar als de software werkt op basis van een (wat ouder) eigen geschreven systeem, dan is daar in mijn ogen niets mis mee, of er hoeft niets mis mee te zijn. Het is ook de aard van de applicatie waar je mee te maken hebt. Is het een simpel CMS om content op een website te toveren, zie ik er niet veel problemen in.

Ik stel ook niet dat het nu goed is te beginnen zonder framework, maar ik vind het te kort door de bocht om te zeggen "een ontwikkelaar die geen standaard framework gebruikt is geen professional", omdat er ook oude(re) applicaties zijn uit de tijd dat die standaard frameworks (of de 1e die er toen was) niet volwassen genoeg was om te gebruiken, of daadwerkelijk overkill voor iets wat gewenst is.

Hydra schreef op dinsdag 15 november 2016 @ 10:34:
[...]


Het gebruik van een framework sluit niet uit dat je de interne werking ervan goed kent. Ik heb zelf veel Spring kennis. Dat is onderdeel van m'n marketability zelf. Hoeveel bedrijven denk je dat geïnteresseerd zijn in mijn kennis van het home-grown Coldfusion framework waar ik in m'n vorige (korte) baan mee gewerkt heb? Dat is exact 1.

Dat stel ik ook niet, ik definieer alleen wanneer ik iemand een professional vindt. Dat jij een framework (of meerdere) kent en kan gebruiken is 1 ding, maar dat je begrijpt wat die doet en waarom dat framework gebruiken een goede keuze is is minstens net zo belangrijk in mijn ogen.

[Cartman!]

jbdeiman schreef op dinsdag 15 november 2016 @ 11:05:
[...]
Je moet wel de tijd investeren om de boel opnieuw op te bouwen met een framework en je daarin te verdiepen. Soms kan dit gewoon niet uit, of is dit niet mogelijk doordat een baas/ manager zit te pushen. (nu kan je je afvragen of de manager dan een professional is, maar dat is een andere discussie.)

Als je die tijd blijft investeren in je eigen bagger of in bestaande en bewezen technologie dan is dat toch een makkelijke keuze?

Maar als de software werkt op basis van een (wat ouder) eigen geschreven systeem, dan is daar in mijn ogen niets mis mee, of er hoeft niets mis mee te zijn. Het is ook de aard van de applicatie waar je mee te maken hebt. Is het een simpel CMS om content op een website te toveren, zie ik er niet veel problemen in.

Dat zijn meestal juist de soort projecten die vol zitten met lekken.

Ik stel ook niet dat het nu goed is te beginnen zonder framework, maar ik vind het te kort door de bocht om te zeggen "een ontwikkelaar die geen standaard framework gebruikt is geen professional", omdat er ook oude(re) applicaties zijn uit de tijd dat die standaard frameworks (of de 1e die er toen was) niet volwassen genoeg was om te gebruiken, of daadwerkelijk overkill voor iets wat gewenst is.

Het is ook erg kort door de bocht natuurlijk maar in mijn ervaring is er wel een zeer grote correlatie tussen die twee.

Dat stel ik ook niet, ik definieer alleen wanneer ik iemand een professional vindt. Dat jij een framework (of meerdere) kent en kan gebruiken is 1 ding, maar dat je begrijpt wat die doet en waarom dat framework gebruiken een goede keuze is is minstens net zo belangrijk in mijn ogen.

Dat is zeker belangrijk. Ik ben er redelijk van overtuigd dat je door het bestuderen van framework code je veel meer leert dan zelf vierkante wielen uit te vinden. Als je een framework op de verkeerde manier gebruikt (ook daarvan iemand in t team gehad) dan kun je er ook flinke bagger mee produceren

Niet onbelangrijk: de doorlooptijd van mijn projecten wisselt een beetje van een week tot 6 maanden, op die manier kun je natuurlijk makkelijker switchen van dingen dan als je aan een legacy project zit wat al jaren live staat. Maar ook in dat geval (wel een paar keer gezien) is het vaak lonend om delen stukje bij beetje te vervangen om een betere/veiligere code base te krijgen.

[jbdeiman]

Cartman! schreef op dinsdag 15 november 2016 @ 11:25:
[...]

Als je die tijd blijft investeren in je eigen bagger of in bestaande en bewezen technologie dan is dat toch een makkelijke keuze?

[...]

Dat zijn meestal juist de soort projecten die vol zitten met lekken.

[...]

Het is ook erg kort door de bocht natuurlijk maar in mijn ervaring is er wel een zeer grote correlatie tussen die twee.

[...]

Dat is zeker belangrijk. Ik ben er redelijk van overtuigd dat je door het bestuderen van framework code je veel meer leert dan zelf vierkante wielen uit te vinden. Als je een framework op de verkeerde manier gebruikt (ook daarvan iemand in t team gehad) dan kun je er ook flinke bagger mee produceren

Niet onbelangrijk: de doorlooptijd van mijn projecten wisselt een beetje van een week tot 6 maanden, op die manier kun je natuurlijk makkelijker switchen van dingen dan als je aan een legacy project zit wat al jaren live staat. Maar ook in dat geval (wel een paar keer gezien) is het vaak lonend om delen stukje bij beetje te vervangen om een betere/veiligere code base te krijgen.

Ik kan mij prima vinden in je redenatie. Het ging mij er vooral om dat er zo kort door de bocht gezegd wordt dat je niet professioneel bent als je geen framework gebruikt.
Natuurlijk wil je op den duur overstappen op gebruik van een goed framework.

Wij hebben de keuze gemaakt de oude applicatie "uit te dienen" (gewoon te onderhouden), en een volledig nieuwe applicatie te bouwen met alle inzichten die we in de loop der jaren hebben opgedaan t.a..v. de sector waarvoor we ontwikkelen.
Dan ga je niet meer investeren in het volledig ombouwen van de bestaande applicatie (10 jaar oud), maar blijf je die onderhouden. Om de mensen die daar (nog steeds) mee werken dan geen professional te noemen gaat mij te ver, en daar is het in mijn reacties om te doen.

[Cartman!]

jbdeiman schreef op dinsdag 15 november 2016 @ 12:18:
Om de mensen die daar (nog steeds) mee werken dan geen professional te noemen gaat mij te ver, en daar is het in mijn reacties om te doen.

Ik mag voor die mensen hopen dat ze niet enkel in die oude bende hoeven te werken en daarnaast ook kunnen meewerken aan nieuwe code die wel gebruik maakt van moderne libraries en frameworks. Zoniet? Dan doen ze zichzelf best te kort qua werk (ik neem namelijk dan aan dat t extreem goed betaalt ).

[jbdeiman]

Cartman! schreef op dinsdag 15 november 2016 @ 12:20:
[...]

Ik mag voor die mensen hopen dat ze niet enkel in die oude bende hoeven te werken en daarnaast ook kunnen meewerken aan nieuwe code die wel gebruik maakt van moderne libraries en frameworks. Zoniet? Dan doen ze zichzelf best te kort qua werk (ik neem namelijk dan aan dat t extreem goed betaalt ).

De betreffende mensen worden omgeschoold in een nieuwe ontwikkeltaal (van PHP naar C# (ASP.NET v 4.5) ) en een nieuw Framework. Dus ja, ze worden langzamerhand omgeschoold en werken niet enkel in die oude bende.

Maar het is voor ons wel een noodzakelijk kwaad de oude bende voorlopig nog te onderhouden, al doen we echt de minimale (wettelijke) wijzigingen in de applicatie en praktisch geen nieuwe / gewijzigde functionaliteiten meer, tenzij de klant daar heel goed voor betaald.

[ Voor 3% gewijzigd door jbdeiman op 15-11-2016 12:52 ]

[Hydra]

jbdeiman schreef op dinsdag 15 november 2016 @ 12:18:
Ik kan mij prima vinden in je redenatie. Het ging mij er vooral om dat er zo kort door de bocht gezegd wordt dat je niet professioneel bent als je geen framework gebruikt.

Moedwillig. Dat leek me duidelijk. Dat je als junior dev in een organisatie weinig in de melk te brokkelen hebt lijkt me evident. Men ageert hier tegen devs die shit produceren, niet tegen de devs die die shit op moeten ruimen.

[Castor385]

Ik ben eigenlijk nog steeds geïnteresseerd in de overweging om alle code zelf te schrijven. Mijns inziens is er veel te zeggen over het zelf schrijven van al je code:

• je hebt amper last van known vulnerablities
• je kent je code door en door
• je hebt veel invloed
• je hoeft compontenten/frameworks niet zelf door te lichten op security risks

Maar het heeft ook nadelen:

• Je zult je zelf moeten wapenen tegen security risico's (bijvoorbeeld: XSS, CSRF, session handling, authentication, authorisation, direct object references, input validation)
• Je schrijft code, wat al door talloze voorgangers is gemaakt
• Je schrijft meer framework code zelf (wat ik zelf veel minder interessant vind dan de functionaliteit van je applicatie)

Hebben jullie nog andere overwegingen die ik nu niet heb opgenoemd?

[ Voor 13% gewijzigd door Castor385 op 15-11-2016 15:05 ]

[Woy]

Modbreak:

Zo is het wel genoeg geweest. We gaan hier niet op de man spelen.

Ik heb off-topic reacties verwijderd!

[Cartman!]

Castor385 schreef op dinsdag 15 november 2016 @ 14:56:
Mijns inziens is er veel te zeggen over het zelf schrijven van al je code:

je hebt amper last van known vulnerablities

Security through obscurity is nooit een goede reden. Dat je code niet bij anderen bekend is betekent niet dat er geen exploits gevonden zullen worden en misbruikt zullen worden. Dit kunnen zelfs hele simpele dingen zijn waar je niet bij stil hebt gestaan (zo ben ik in het verleden met een eigen framework eens nat gegaan op null byte injection).

je kent je code door en door

Eens maar dat kan bij frameworks ook natuurlijk. Door en door kennen kan ook betekenen dat je weet waar de zwakke plekken zitten die je eigenlijk zou willen verbeteren.

je hebt veel invloed

Zeker, maar daar staat tegenover dat (bijna) niemand je tegen houdt om slechte code te schrijven of bad practices toe te passen.

Zelf denk ik dat het grotendeels gebaseerd is op onzekerheid, het is nieuw en het gaat tijd kosten er mee om te kunnen gaan.

[ Voor 12% gewijzigd door Cartman! op 15-11-2016 15:09 ]

[Castor385]

Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman. Uiteindelijk gaat de hacker daar naar waar het slot het zwakst is (of waar de deur open staat). Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

[Cartman!]

Castor385 schreef op dinsdag 15 november 2016 @ 15:19:
Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman.

Ik vind dat wel wat naief eigenlijk, je gaat er dan een beetje vanuit dat een kwaadwillende een keuze maakt op basis van de fouten van een ander. Dat werkt misschien bij scriptkiddies zo maar niet bij iedereen. Als er bij jou (danwel de server waar jij op zit die je misschien deelt met anderen) dan kan het totaal geen verschil maken.

Uiteindelijk gaat de hacker daar naar waar het slot het zwakst is (of waar de deur open staat). Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

Daar gaat het dus om... als jij iets zelf maakt dan ga je niet weten of er wel of geen exploits inzitten omdat je immers gelimiteerd bent door je eigen kennis van exploits. Ik ben ooit eens (in een security scan) gewezen op null byte injections in een oud framework wat ik had gemaakt waar ik nog nooit van gehoord had... Als je het niet kent kun je je er ook niet tegen wapenen terwijl als je met heel veel mensen open source iets maakt de kans dat iemand het spot en fixt veel groter is dan jij in je eentje.

[Hydra]

Castor385 schreef op dinsdag 15 november 2016 @ 15:19:
Mee eens dat Security through obscurity op zichzelf geen goede reden is, maar het maakt jouw applicatie wel net ff iets minder makkelijk te hacken dan dat van je buurman.

Juist niet. Home grown stuff is een prime target juist omdat daar vaak nog wat te halen valt.

Je zult zelf natuurlijk wel moeten zorgen dan er geen exploits in je code zitten, anders staat de spreekwoordelijke deur gewoon gigantisch open met een neon reclame bord ernaast.

Euh tja. "Gewoon geen fouten maken". Was het leven maar zo simpel

[ Voor 26% gewijzigd door Hydra op 15-11-2016 15:31 ]

[Castor385]

Hydra schreef op dinsdag 15 november 2016 @ 15:30:
[...]


Juist niet. Home grown stuff is een prime target juist omdat daar vaak nog wat te halen valt.

Ik heb mijn beredenering niet goed geformuleerd denk ik. Wat ik bedoel:
Als je twee applicaties hebt, die beiden van dezelfde techniek gebruik maakt, dan is degene waarbij security through obscurity wordt toegepast, net iets minder makkelijk te hacken dan de applicatie die dat niet heeft.

Ik bedoel hier niet dat security through obscurity op zichzelf voldoende is. Verre van dat!


Overigens ben ik zelf van mening dat je beter gebruik kan maken van goed aangeschreven frameworks omwille van security risks en productiviteit, maar ik kan me voorstellen dan niet iedereen dezelfde mening heeft en misschien een uiterst slechte ervaring heeft gehad, juist door frameworks te gebruiken.

[ Voor 20% gewijzigd door Castor385 op 15-11-2016 15:36 ]

[Cartman!]

Dat hangt er nog steeds vanaf of de rest van het systeem al niet zo lek is als een mandje. Je kan dingen wel obscuur maken maar als ze fundamenteel onveiliger zijn dan heb je daar helemaal niks aan. Het zou enkel opgaan als beide systemen identiek zijn en je bij 1 van de 2 daar nog extra dingen aan toegevoegd hebt.

[Hydra]

Castor385 schreef op dinsdag 15 november 2016 @ 15:34:
Ik heb mijn beredenering niet goed geformuleerd denk ik. Wat ik bedoel:
Als je twee applicaties hebt, die beiden van dezelfde techniek gebruik maakt, dan is degene waarbij security through obscurity wordt toegepast, net iets minder makkelijk te hacken dan de applicatie die dat niet heeft.

Je misbruikt de term. "Beveiliging door middel van onduidelijkheid" is compleet wat anders dan "extra beveiliging dankzij obfuscation". Security through obscurity is het eerste, niet het tweede. Niemand bestrijd het nut van obfuscation als extra maatregel.

[Castor385]

Je hebt gelijk, ik heb inderdaad de term niet goed gebruikt.