[PHP] 3 tier model vs prestaties

Pagina: 1
Acties:
  • 515 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Sjoerd
  • Registratie: December 2003
  • Niet online
Momenteel heb ik in vb.net het 3 tier model geleerd, ik zou dit graag gaan toepassen in mijn php projecten ivm overdraagbaarheid en alle andere voordelen die het met zich mee brengt.

Echter vraag ik me af of dit niet enorm veel load gaat veroorzaken tegen over de traditionele manier die ik nu gebruik:

index.php
vraag gegevens aan core.class.php die querys uitvoerd
(gebruikt database.class.php)

dit zou met het 3 tier model worden

index.php
vraag gegevens aan core.class.php
vraagt gegevens aan tabelnaam.class.php die querys uitvoerd
(gebruikt database.class.php)


Hoe zijn hier de ervaringen mee? :) ivm prestaties dan met name ;)

Modelbouw - Alles over modelbouw, van RC tot diorama


Acties:
  • 0 Henk 'm!

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

De extra load is meestal minimaal. In principe verplaats je de code naar een andere laag. Als je de meerdere lagen goed verwerkt dan het zelfs zijn dat je per saldo zelfs minder code include dan nu omdat je veel code op meerdere plaatsen kunt gebruiken.

Wat betreft executie tijd kun je mogelijk een klein prestatie verlies krijgen, maar het is vrij eenvoudig om de machine zwaarder (snellere cpu, meer geheugen, etc) te maken of zelfs een extra webserver bij te schakelen. Als je het meer lagen model goed implementeert zal ook development tijd verkorten waardoor je ook indirect geld bespaard.

Ik dacht dat PHP ook wel een aantal cache mogelijkheden voor veel gebruikte bestanden heeft. Ik weet dat zo'n 3 jaar geleden daar wel aan werd gewerkt door Zend, maar weet niet of dat in de final PHP5 terrecht is gekomen. Mogelijk is het als een pecl extentie beschikbaar gemaakt..

If it isn't broken, fix it until it is..


Acties:
  • 0 Henk 'm!

  • HawVer
  • Registratie: Februari 2002
  • Laatst online: 13-09 16:51
Sjoerd schreef op maandag 07 januari 2008 @ 12:40:
Momenteel heb ik in vb.net het 3 tier model geleerd, ik zou dit graag gaan toepassen in mijn php projecten ivm overdraagbaarheid en alle andere voordelen die het met zich mee brengt.

Echter vraag ik me af of dit niet enorm veel load gaat veroorzaken tegen over de traditionele manier die ik nu gebruik:

index.php
vraag gegevens aan core.class.php die querys uitvoerd
(gebruikt database.class.php)

dit zou met het 3 tier model worden

index.php
vraag gegevens aan core.class.php
vraagt gegevens aan tabelnaam.class.php die querys uitvoerd
(gebruikt database.class.php)


Hoe zijn hier de ervaringen mee? :) ivm prestaties dan met name ;)
Een goed opgezette structuur biedt veel voordelen o.a. flexibiliteit. Het verschil in performance is absoluut acceptabel. Zeker omdat php erg snel is met het invoegen en laden van bestanden.

http://hawvie.deviantart.com/


Acties:
  • 0 Henk 'm!

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 22:47
In mijn ervaring zijn het vooral de databasequeries die een site traag maken, vooral als er veel data in staat. Een extra verwijzing naar een andere class kost je iets performance maar in een verwaarloosbare hoeveelheid.

Daarnaast wat al gezegd werd: als je goed abstract code hoef je netto minder code te includen zodat het geheugenverbruik van je applicatie alleen maar afneemt :)

[ Site ] [ twitch ] [ jijbuis ]


Acties:
  • 0 Henk 'm!

  • Face_-_LeSS
  • Registratie: September 2004
  • Niet online
Enkele duizenden includes van klasse bestanden stelt voor php niet zo veel voor hoor. Test het voor de grap maar eens.

Laatst heb ik gespeeld met een soort van library systeem voor php met een 'import' functie voor klassen.
In ieder klasse bestand riep ik de functie 'import' om alle klassen waarvan dat bestand gebruik maakte te importeren. Die functie 'import' controleerde of de klasse al aanwezig was, zo niet dan werd deze geladen.

voorbeeld:

PHP:
1
2
3
4
5
6
7
8
9
10
import('MyLib.ArgumentNullException');
import('MyLib.InvalidOperationException');
import('MyLib.Security.IUserProvider');
import('MyLib.Security.UserProviderBase');
enz...

class DbUserProvider extends UserProviderBase implements IUserProvider
{
 // class content
}


Werkt op zich wel leuk, en was bij 10.000 imports nog steeds rete snel.


// edit
Tevens volstaat PDO in de meeste gevallen al als data-tier dus dan hoef je er nog maar 2 te maken ;)

[ Voor 6% gewijzigd door Face_-_LeSS op 07-01-2008 19:49 ]


Acties:
  • 0 Henk 'm!

  • Sjoerd
  • Registratie: December 2003
  • Niet online
@Face__Less eigenlijk hetzelfde als de function __autoload($class_name) ? of toch iets anders?

Ik ben begonnen praktisch een opzetje te maken in PHP maar het blijkt toch lastiger dan in vb.net

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[b]index.php[/b]
include includes/config.php
include includes/autoload.inc.php
$user=new users();
echo $user;


[b]users.class.php[/b]
public id
public name
public email
public ...
function __construct(){
 $data=new userData();
 $this->name=$data->getUserName();
}



[b]userData.class.php[/b]

public function getUserName(){
sql query ("select name from users")
}


Klopt dit schematische ontwerpidee ongeveer?

Modelbouw - Alles over modelbouw, van RC tot diorama


Acties:
  • 0 Henk 'm!

  • Face_-_LeSS
  • Registratie: September 2004
  • Niet online
Sjoerd schreef op maandag 07 januari 2008 @ 20:38:
@Face__Less eigenlijk hetzelfde als de function __autoload($class_name) ? of toch iets anders?
Doh 8)7 Die functie is vast nog velen malen sneller. PHP blijft me verrassen.
Gelukkig was ik er maar mee aan het spelen :)

// edit
Mijn functie is toch iets anders. Ik implementeer nog een soort 'namespace' systeem. Dus in een config bestand declareer ik het base-path van de libraries en hun base-namespace naam. En include via die import functie het goede bestand uit de goede library bijv:
PHP:
1
import('MyLib.MyNamespace.MyClass');

[ Voor 33% gewijzigd door Face_-_LeSS op 07-01-2008 21:36 ]


Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Wat je dus eigenlijk wil is een simpele O/R mapper maken? ;)

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • Sjoerd
  • Registratie: December 2003
  • Niet online
SchizoDuckie schreef op maandag 07 januari 2008 @ 21:36:
Wat je dus eigenlijk wil is een simpele O/R mapper maken? ;)
ik denk dat het dat inderdaad is.
Nadeel lijkt me ook wel dat ik enorm veel files krijg, maar was mijn bovenstaande opzet goed?

en dan de mappen structuur:

index.php
bslibs (basis classes)
dblibs ('database' classes)

:)

Modelbouw - Alles over modelbouw, van RC tot diorama


Acties:
  • 0 Henk 'm!

  • Face_-_LeSS
  • Registratie: September 2004
  • Niet online
Tier 1: Presentatie
Zou index.php kunen zijn. Die gebruik maakt van een RequestHandler klasse die aan de hand van de POST/GET parameters besluit hoe de aanvraag afgehandeld moet worden, spreekt de controller aan en genereert output (HTML / XML / JSON / You Name It).

Tier 2: Buisiness/Logic (Controller klassen)
Alle klassen die met buisiness logic te maken hebben. Dus buisiness objecten en klassen met buisiness functionaliteit (denk aan het registreren/toevoegen/verwijderen van gebruikers, het inloggen enz.)

Tier 3: Data
In veel gevallen volstaat PDO al. De meeste websites in php zijn relatief eenvoudig en gebruiken alleen een database als opslag.
Wanneer dit niet het geval is, of wanneer je het leuk vind om generiek te werken kan je een soort interface systeem maken tussen de buisiness en de data layer. De buisiness layer gebruikt dan die interfaces om data op te halen van de data layer, het maakt dan voor de buisiness layer niet uit of die data dan via PDO of via welke andere datasource dan ook binnen gehaald word.


Naast deze layers kan je ook nog enkele application klassen maken. Daarin verwerk je eventuele niet buisiness functionaliteit en functionaliteit die vrij algemeen is. Zoals configuratie van de applicatie en andere standaard en veelgebruikte zaken.

Dit is een vrij simpel opzetje maar kan zo generiek opgezet worden als je zelf wilt. Ik heb zelf nog nooit een compleet systeem gemaakt in php dus misschien is het niet waterdicht (eventuele op-/aanmerkingen zijn welkom natuurlijk).


De mappen structuur maakt niks uit voor het lagen systeem, zolang de klassen maar ge-include worden. Makkelijk is om het overzichtelijk te houden en duidelijke namen te gebruiken die duidelijk weergeven wat een klasse doet. Gebruik van Pascal casing kan wel handig zijn.

"DbUserAccountManager.php" zegt meer dan "dbusrackntmgr.php"

Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Sjoerd schreef op dinsdag 08 januari 2008 @ 08:03:
[...]

ik denk dat het dat inderdaad is.
Nadeel lijkt me ook wel dat ik enorm veel files krijg, maar was mijn bovenstaande opzet goed?

en dan de mappen structuur:

index.php
bslibs (basis classes)
dblibs ('database' classes)

:)
ik gooi meetsal al m'n classes in 1 'includes' dir. Dan kan je met __autoload() automagisch de classes inladen die je in je code gebruikt :) Je kan overigens wel het beste je config filetje met db login info buiten je wwwroot laten ;)

Op de site in m'n sig staat overigens wel een example waarmee je wat kan stoeien en een berg uitleg :)

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 22:47
SchizoDuckie schreef op dinsdag 08 januari 2008 @ 10:10:
ik gooi meetsal al m'n classes in 1 'includes' dir. Dan kan je met __autoload() automagisch de classes inladen die je in je code gebruikt :)
Idem, maar met de additie dat classes binnen 1 group in een subfolder staan.

Ergo, de class AccountRegistration bijvoorbeeld staat in /Account/Registration.class.php - evenzo staat de class Account weer in /Account/class.php - met in elk bestand 1 class (en optioneel een exceptionclass die erbij hoort).

Op het moment werk ik aan een site met een kleine 120 classes, dan ben je blij dat ze niet allemaal in dezelfde folder staan :+

[ Site ] [ twitch ] [ jijbuis ]


Acties:
  • 0 Henk 'm!

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

__autoload() moet je zeker niet gebruiken als je van een multi-tier model gebruik maakt. Je weet toch zelf welke classes je moet gebruiken? Dat weet je ook welke bestanden je met include_once moet inladen.

Als je in elk bestand alle includes opneemt kun je met een simpele search alle scripts terug vinden welke gebruik maakt van dat bestand. Als je aan het refactoren bent, is dat heel erg fijn.

Daarnaast vind ik het persoonlijk erg fijn om een directory structuur op basis van de namespace aan
te houden. Daarnaast wordt hier gevraagd om het gebruik van meerdere lagen een performance verlies oplevert. Heeft iemand er uberhaupt over nagedacht hoe __autoload werkt? Dat PHP abacadabra weet dat class 'XXX' in bestand ./abc/def.php staat? Elke keer als PHP zelf het bestand moet achterhalen wordt er een search in de opgegeven folders uitgevoerd. Dit kost meestal aardig wat disk resources en daarmee krijg je dus automatisch performance verlies. En hoeveel classes gebruik je nou normaal in 1 script? ik denk dat als je 5 a 6 classes in 1 script nodig hebt dat je over veel praat. De meeste classes laden namelijk zelf de classes waarvan zij afhankelijk zijn.

Maar je hebt ook veel programmeurs die bij een query altijd select * from gebruiken terwijl ze precies weten welke velden ze nodig hebben. Bij gebruik van * in een query vraag je de database om de velden op te zoeken. Ook dat kost tijd en zorgt dus voor performance verlies. Je hebt het misschien over 2 milisecondes per query. Maar heb je enig idee hoeveel queries er op een enkele pagina worden uitgevoerd? Wij hebben zo'n 1,5 miljoen sessies per dag bij zo'n 27 miljoen hits. En bij die aantallen kunnen milisecondes besparing een website ineens een stuk sneller maken.

If it isn't broken, fix it until it is..


Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Sjoerd schreef op maandag 07 januari 2008 @ 20:38:
@Face__Less eigenlijk hetzelfde als de function __autoload($class_name) ? of toch iets anders?

Ik ben begonnen praktisch een opzetje te maken in PHP maar het blijkt toch lastiger dan in vb.net

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[b]index.php[/b]
include includes/config.php
include includes/autoload.inc.php
$user=new users();
echo $user;


[b]users.class.php[/b]
public id
public name
public email
public ...
function __construct(){
 $data=new userData();
 $this->name=$data->getUserName();
}



[b]userData.class.php[/b]

public function getUserName(){
sql query ("select name from users")
}


Klopt dit schematische ontwerpidee ongeveer?
Op een paar punten na wel ongeveer. Maar die paar punten he...

In je index maak je een nieuwe klasse genaamd 'users' aan, echter, de naamgeving daarvan geeft al aan dat het gaat om een verzameling (of collection van users. Verzameling-klassen worden eigenlijk nooit specifiek voor een bepaald type data gebruikt (users, zoals in jouw voorbeeld). In de plaats daarvan kun je beter gewoon arrays gebruiken (op een laag niveau), of een collection class (een class List, bijvoorbeeld), die arrays gebruiken om de data op te slaan maar extra functionaliteit toevoegen aan zo'n lijst, zoals zoekfuncties, sorteren, dat soort grappen.

In je tweede class, de User class, begint het goed - je hebt velden (of variabelen) waar je de gegevens met betrekking tot een user opslaat, maar het gaat (ontwerptechnisch gezien) mis bij de constructor. Voor zover ik kan zien laat je de User class zichzelf vullen met gegevens (uit een db, bijvoorbeeld), wat eigenlijk iets is wat je niet wilt hebben, aangezien je een data-klasse een tweede rol als data access object geeft.

Een betere structuur in dat gebied zou als volgt zijn:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class User {

   private $id;
   private $fiets;
   private $name;

   public __construct($id, $fiets, $name) {
      $this->id = $id;
      $this->fiets = $fiets;
      $this->name = $name;
   }

   public setId($id) {
     $this->id = $id;
   } 

   public getId() {
      return $this->id;
   }

   // nog meer van die getters / setters voor elke data.
}


(Noot: De velden in een object zijn niet direct aanspreekbaar van buitenuit. Door deze structuur (wat vaak voorkomt in Java programmatuur) te gebruiken, kun je bijvoorbeeld validatie uitvoeren (evt met gebruik van exceptions). Maar het is vooral handig wanneer je nog een bewerking wilt uitvoeren op je gegevens wanneer ze toegevoegd of ingelezen worden uit je User object, zo hoef je alleen maar binnenin je User klasse wat te veranderen, niet in alle aanroepen)

(Noot 2: Ik heb (in vergelijking met Java) maar bar weinig ervaring met proper OO PHP)

En vervolgens een UserDao (User Data Access Object):

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class UserDao {

   private $db; // database / data object
   // (normaalgesproken zou je een verwijzing naar een databaseobject waarschijnlijk in een centrale ' dao'-klasse stoppen, die elke DAO extendt. Of gebruik maken van een database factory)

   public __construct($db) {
     $this->db = $db;

   }

  public get($id) {
     $userdata = $db->get("from user where id="+$id"); // voorbeeld, gebruik je fantasie bij zoiets.
   
     $result = new User($userdata['id'], $userdata['fiets'], $userdata['name']);

    return $result;
  }
 

   // zoekfuncties
   public find($query);
   public findByName($name);
   public findById($id);
   public findByFiets($fiets);
 
   //verwijder user per id
   public remove($id);
   // verwijder user per user object
   public remove($user);
 
   // sla nieuwe user op of update bestaande user
   public save($user);

   //etc
}


Zo hou je de data (User class) en data access (database interactie classes) gescheiden. Als een User zichzelf moet kunnen beheren, is het einde nabij :+.

Acties:
  • 0 Henk 'm!

  • Face_-_LeSS
  • Registratie: September 2004
  • Niet online
Zo doe ik het graag:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// Buisiness object
class User
{
    private $_name;
    private $_email;

    // getters & setters
}

// Interface voor welke datasource dan ook om gebruikers te beheren
interface IUserManager
{
    public function GetUser($name);
    public function GetUsers($filter = null);
    public function AddUser($name, $email, $....);
    public function DeleteUser($name);
    public function SaveUser($name);
}

// Klasse om gebruikers in een database te beheren.
class DbUserManager implements IUserManager
{
    // implementeer methoden  van IUserManager
}

// Klasse voor het aanmaken van een IUserManager, bijv. gebaseerd op een configuratie.
class UserManagerFactory
{
    public static function CreateUserManager()
    {
         // Maak een usermanager gebaseerd op de configuratie ofzo.
        return new DbUserManager();
    }
}

// Klasse die aangesproken wordt vanuit de pressentatie laag voor gebruikers beheer. 
class UserManagement
{
    public static function CreateUser($name, $email, $...)
    {
        $userManager = UserManagerFactory::CreateUserManager();
        if($userManager->GetUser($name) !== null)
        {
            throw new Exception('User exists!!');
        }
        $userManager->CreateUser($name, $email, $...);
    }

    public static function DeleteUser($name
    {
        $userManager = UserManagerFactory::CreateUserManager();
        if($userManager->GetUser($name) === null)
        {
            throw new Exception('User does not exists!!');
        }
        $userManager->DeleteUser($name);
    }
}



en dan zo kan je een gebruiker toevoegen

PHP:
1
2
3
4
5
6
7
8
try
{
    UserManagement::CreateUser('Sinterklaas', 'sint@sintenpiet.nl', ....);
}
catch (Exception $ex)
{
    echo $ex->getMessage();
}


Deze manier is toepasbaar voor veel aspecten in een applicatie en is erg overzichtelijk vind ik.

Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Niemand_Anders schreef op dinsdag 08 januari 2008 @ 13:06:
__autoload() moet je zeker niet gebruiken als je van een multi-tier model gebruik maakt. Je weet toch zelf welke classes je moet gebruiken? Dat weet je ook welke bestanden je met include_once moet inladen.
Sorry maar als je met dit soort 'adviezen' komt wil je dan please gewoon niets zeggen? Er is *absoluut* niets mis met het gebruik van __autoload() en als dat er wel is hoop ik dat je dat nog even goed wil onderbouwen.

Als je slim bent zorg dat al je requests gewoon binnenkomen in je index.php via de rewrite engine en dat je daar je request verder verdeelt. Zo heb je include_once en dat soort meuk helemaal niet nodig. Verder is het hele factory model precies iets wat java users veel gebruiken. Vaak is het alleen gewoon zwaar overbodig voor de gemiddelde website.

Ik doe het zo:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
global $_URI;
// config zut hier of in een aparte file
include('./includes/functions.php');

$_URI = explode('/', $_SERVER['REQUEST_URI'];

loadPlugins('./plugins'); //loadPlugins include()'t alle plugins uit de plugins dir.

/*
 elke 'plugin' (een plain PHP file'tje met 1 switch() erin) doet ongeveer dit:

switch($_URI[0])
{
 case 'dingetje: 
   // hier relevante code voor dingetje.
  break;
}
*/

include('template.inc.php');


PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$users = dbObject::Search('User', array('User_ID > 100', array('Disabled' => 0)); // fetcht een array van ge-or-mapte User objecten met user_id > 100 en disabled = 0

if($users) // static Search functie geeft false als er geen results zijn
{ 
 foreach($users as $curentUser)
 {
 $currentUser->deleteYourSelf(); // deleteYourSelf() functie komt standaard uit de dbObject class.
 }
}

$user = new User(); // nieuw leeg object maken.
$user->Name = 'Pietje';
$user->Password = md5('woei');
$user->Save(); // Save() functie komt ook standaard uit dbObject class en insert automagisch een record en geeft een primary id terug.


Ieder z'n eigen favo manier dus, er is niet echt een best practice wat dat betreft, dat hangt af van hoeveel complexiteit je zelf op prijs stelt en hoe je database is opgezet en hoeveel custom stuff je moet doen :)

[ Voor 60% gewijzigd door SchizoDuckie op 08-01-2008 15:16 ]

Stop uploading passwords to Github!


Acties:
  • 0 Henk 'm!

  • Sjoerd
  • Registratie: December 2003
  • Niet online
bedankt voor alle reacties iedereen zie hier scriptjes voorbij komen waar ik soms nog ogen bij trek, bijvoorbeeld die 'interface nog niet eerder gebruikt eigenlijk :)

enige dat ik niet snap aan het bovenstaande voorbeeld is

// Maak een usermanager gebaseerd op de configuratie ofzo.
return new DbUserManager();


dat stukje ontgaat me even :)

Modelbouw - Alles over modelbouw, van RC tot diorama


Acties:
  • 0 Henk 'm!

  • Face_-_LeSS
  • Registratie: September 2004
  • Niet online
Sjoerd schreef op dinsdag 08 januari 2008 @ 15:04:
enige dat ik niet snap aan het bovenstaande voorbeeld is

// Maak een usermanager gebaseerd op de configuratie ofzo.
return new DbUserManager();


dat stukje ontgaat me even :)
Door met zo'n factory pattern te gebruiken heb je één methode om, in dit geval, een "UserManager" te creëren. Deze retourneert een interface van het type IUserManager. Dat is een stukje abstractie, lang niet altijd nodig maar kan soms goed van pas komen.

Wanneer je die factory zo programeert dat deze bijvoorbeeld aan de hand van een configuratie het juiste type "UserManager" initialiseert en retourneert ben je lekker OO en generiek bezig.
Stel je wilt later je users uit een andere datasource wilt halen (ActiveDir / XML bestand / ofzo) dan hoef je alleen een nieuw type "UserManager" die de interface IUserManager implementeert te programmeren en de configuratie aan te passen.
Uiteraard is dat lang niet altijd nodig, maar het is wel overzichtelijk en kan op een gegeven moment tijdwinst opleveren.


PHP:
1
return new DbUserManager();

Dat was alleen even als voorbeeld, het initialiseren van het juiste type "UserManager" moet eigenlijk aan de hand van een configuratie.

Dit is misschien interessant om eens door te nemen.

Acties:
  • 0 Henk 'm!

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

SchizoDuckie schreef op dinsdag 08 januari 2008 @ 15:04:
[...]


Sorry maar als je met dit soort 'adviezen' komt wil je dan please gewoon niets zeggen?

Als je slim bent zorg dat al je requests gewoon binnenkomen in je index.php via de rewrite engine en dat je daar je request verder verdeelt. Zo heb je include_once en dat soort meuk helemaal niet nodig. Verder is het hele factory model precies iets wat java users veel gebruiken. Vaak is het alleen gewoon zwaar overbodig voor de gemiddelde website.
Java zoekt de bestanden het compileren bij elkaar. __autoload() doet dit runtime. Dat zoeken kost tijd, terwijl je precies weet welke classes je wilt gebruiken: include_once("Profile/User.php"); is dus sneller (performance wise gezien) dan de __autoload().

index.php gebruiken om alles te kunnen tonen/doen? Ik weet niet welke ICT opleiding jij hebt gehad, maar ik hoop niet dat je het zo geleert hebt.
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$users = dbObject::Search('User', array('User_ID > 100', array('Disabled' => '0)); // fetcht een array van ge-or-mapte User objecten met user_id > 100 en disabled = 0

if($users) // static Search functie geeft false als er geen results zijn
{ 
 foreach($users as $curentUser)
 {
 $currentUser->deleteYourself(); // delete() functie komt standaard uit de dbObject class.
 }
}

$user = new User(); // nieuw leeg object maken.
$user->Name = 'Pietje';
$user->Password = md5('woei');
$user->Save(); // Save() functie komt ook standaard uit dbObject class en insert automagisch een record en geeft een primary id terug.


Je hoeft in dit script dus alleen maar user.php te included. user.php zelf laad de DAL, welke op zijn beurt weer de database classes laad. Er zijn geen onbekende classes, dus er is ook geen noodzaak om __autoload() te gebruiken.
Ieder z'n eigen favo manier dus, er is niet echt een best practice wat dat betreft, dat hangt af van hoeveel complexiteit je zelf op prijs stelt en hoe je database is opgezet en hoeveel custom stuff je moet doen :)
Er wordt ook niet gevraagd om een best practice, maar de discussie gaat erover of code opsplitsen naar multi-tiers performance winst of verlies oplevert. Gebruik van meerdere programmeer lagen kan een performance winst opleveren, maar dan moet je geen functies gebruiken welke eventuele winst zo de grond weer inboren zoals __autoload().

Zoals gezegd weet elke class precies welke andere classes nodig zijn. Dan kun je die ook simpelweg included. Om ervoor te zorgen dat classes niet dubbel geinclude worden gebruik je include_once of require_once. Maar ook op de php pagina zelf weet je welke classes je nodig hebt. Nog los van het feit dat je met include/require eenvoudiger het overzicht kunt behouden. Iets wat zeer belangrijk is als met grote teams wordt gewerkt.

Dan kun je wel zeggen dat mijn post onzinnig is, maar je hebt geen argument gegeven waarom je WEL __autoload() zou moeten gebruiken.

If it isn't broken, fix it until it is..


Acties:
  • 0 Henk 'm!

  • SchizoDuckie
  • Registratie: April 2001
  • Laatst online: 18-02 23:12

SchizoDuckie

Kwaak

Niemand_Anders schreef op dinsdag 08 januari 2008 @ 15:42:
[...]

Dan kun je wel zeggen dat mijn post onzinnig is, maar je hebt geen argument gegeven waarom je WEL __autoload() zou moeten gebruiken.
• Omdat je ál je classes van een andere plek zou kunnen inladen door enkel en alleen je __autoload() functie aan te passen
• het performance verschil tussen include_once versus __autoload() is een micro optimalisatie. Als je dit nodig hebt om het laatste beetje performance uit je scripts te persen doe je überhaupt iets fout.
• Mijn classes hebben geen referenties nodig naar andere classes, welke weer precies in de juiste volgorde ingeladen moeten worden, want __autoload() doet ook gewoon een include_once. Zo wordt een class niet overbodig ingeladen als het niet nodig is en hoef je wederom geen harde references tussen je classes te knopen.
• __autoload() zou zelfs performance kunnen winnen aangezien deze alleen aangeroepen wordt als een class nog niet ingeladen is. Jouw include_once() wordt altijd ingeladen ;)

Verder is er ook nog wel het een en ander geschreven over deze functie:
[google=__autoload optimize]
index.php gebruiken om alles te kunnen tonen/doen? Ik weet niet welke ICT opleiding jij hebt gehad, maar ik hoop niet dat je het zo geleert hebt.
Zullen we even niet op de man gaan spelen? Ik heb al aardig wat jaartjes ervaring met hoe dingen handig en simpel opgezet moeten worden en een 'ict opleiding' zegt daar geen zak over ;)

Ik durf zelfs wel te beweren dat mijn eigen opzet een van de meest modulaire, portable, simpel te doorgronden en cleane mvc site structuren is die er zijn.

[ Voor 9% gewijzigd door SchizoDuckie op 08-01-2008 16:24 ]

Stop uploading passwords to Github!

Pagina: 1