Ontwerppatroon toepassen i.c.m database connectie

[4Real]

Voor een lange tijd gebruik ik een singleton class om mijn database connectie te beheren. Vooral in PHP is dit een erg makkelijke oplossing aangezien gros van de applicaties die ik maak één database gebruiken. Toch twijfel ik nog aan de implementatie en op internet lees ik ook dat je singleton patroon moet vermijden. Echter zit ik dan te zoeken naar een mooie oplossing van doorgeven van database connectie(s). Of hoe je de connectie string moet doorgeven wanneer je iets van database A naar B wil kopieren, dan moet je dus eerst twee connecties openen en deze op een bepaalde manier weer tevoorschijn halen.

Een voorbeeld hoe ik nu mijn patroon toepas:

PHP:

class User
{
    public $Firstname;
    public $Lastname;

    public function Save()
    {
        $db = Database::GetInstance();

        // query opbouwen en verwerken.
    }
}

Deze oplossing is puur gemaakt voor één connectie. Wanneer ik iets van database A wil ophalen, verwerken en wegschrijven naar een andere database B dan zal deze oplossing totaal niet werken en zal ik de Save functie moeten herschrijven.

Nu kan ik een abstract model class maken, welke eigenlijk elke tabel in mijn database vertegenwoordigd.

PHP:

abstract class Model
{
    private $_Db;
    public function __construct($db)
    {
        $this->_Db = $db;
    }
}

class News extends Model
{

}

De class news overerft model en heeft zodoende opslag voor de database connectie. Via de constructor kan ik deze doorgeven en verschillende database connecties kunnen gebruikt worden om items op te slaan. Echter vind ik het niet echt een mooie oplossing om steeds overal de database connectie door te moeten geven.

Na een tijdje te hebben rond gekeken zag ik de factory patroon. Zo kun je je model classes helemaal opbouwen, zodat deze zelfstandig in een applicatie kunnen werken (dus absoluut geen relatie hebben met een database) en in de factory kun je gebruik maken van database connecties. En hierdoor kwam ik op het volgende uit.

PHP:

class UserFactory
{
    public static function GetUserByID($id, $db)
    {
        
    }
}

Op deze manier kan ik één instantie van een user ophalen van database A en zo doorsturen naar database B. Bij het voorbeeld hierboven waar de database connectie wordt doorgegeven zou ik een nieuwe instantie moeten maken en alle variabelen moeten overgeven. Ook niet echt handig. Dus kwa gebruiksvriendelijkheid zou ik zeggen dat deze mijn voorkeur heeft.

Nu komt alleen laatste punt, ik gebruik een MVC framework en ver in begin van de code maak ik de database connecties al aan aangezien de code daarna allemaal classes/functies induikt. Nu komt de vraag hoe krijg ik de connectie(s) toch beschikbaar ergens diep in de code? Waar voor mij het programmeren begint is in één van de functies van een controller. De frontcontroller is altijd beschrikbaar (nu bedenk ik mij net dat het komt omdat die ook een singleton is), maar goed dat is maar even zo. Is het dan verstandig om een Register class op te nemen waar ik global variabelen kan parkeren en op kan pikken wanneer ik deze nodig heb. Of zijn er betere implementaties om dit probleem op te lossen?

[Cartman!]

Kijk eens naar Doctrine ORM, het is niet echt snel maar wel heel flexibel en het werkt fantastisch.

Heb je een use-case waarbij je 2 databases nodig hebt? Ik zou zelf eerder denken aan een API die de 2 apps met elkaar kan verbinden namelijk. Overigens biedt Doctrine wel ondersteuning voor meerdere verbindingen.

[Solarsparc]

Model classes helemaal los houden van een database is heel nobel maar werkt in de praktijk niet echt. Wat de ORM's veelal doen en wat voor niet-al-te-mega-grote projecten werkt is een Domain Driven Design-aanpak, waar je slimme models hebt die alle business logic bevatten, zodat je niet heel veel losse onderdelen hoeft te gaan managen; dat is wat het factory pattern zoals je het hierboven schetst, wel oplevert: je moet overal je database meegeven.
Wil je perse niet je databasegebeuren in je models, dan kun je een repository / DAO-structuur opzetten. Ieder model heeft dan een corresponderende DAO of repository met high-level methods zoals getById($id), getByName("name"), etc. en daar wordt de databaselogica ook in afgehandeld. Het is niet ongewoon om vanuit die classes een singleton-connectie bij te houden naar een database. Wil je dat perse niet, dan kun je iets proberen als Dependency Injection - ik weet niet of daar een beetje een net framework voor is in PHP, maar dat zorgt er in ieder geval voor dat je constructor-variabelen (bijv. in je DAO) automatisch gewired worden naar een connectie-instantie, en die connectie kun je weer wiren met een factory, bijvoorbeeld. Dan wordt het patroon ongeveer als volgt: UserDAO dao = new UserDAO($eenDbContext), de DAO construeert middels een factory (die onder water kan bepalen of steeds dezelfde instance wordt teruggegeven of een nieuwe) de juiste database-instantie. Die DbContext kan gewoon een stringetje zijn, maar ook via een factory een complexer object (je wilt die verantwoordelijkheid eigenlijk niet in de DAO-factory).

Als je echter moderne ORMs als ActiveRecord, Doctrine of zelfs Hibernate gewend bent, zul je je afvragen waarom je ooit meer zou willen doen dan User.find($someId).
Van de ene database naar de andere is iets wat misschien wat meer denkwerk vergt, maar je moet vooral nu niet al je single-database apps zo gaan programmeren dat ze eventueel in de toekomst met 2 databases kunnen werken, kost alleen maar werk en You Ain't Gonna Need It. Sowieso kun je je afvragen of databasetabellen schuiven uberhaupt via je modellaag moet lopen, of dat je beter op tabelniveau kunt werken. Maar zelfs op modelniveau zou ik niet gauw meer willen doen dan $user.save($2ndDbContext) en dat dan alleen gebruiken als ik ook echt een 2de database gebruik, $user.save() zou dan altijd de default gebruiken.

Verder wil ik nog zeggen: singletons zijn evil, maar op een aantal plekken is het wel degelijk de goede oplossing. Logging is daar een voorbeeld van, maar een databaseconnectie in veel gevallen ook. Het wordt ook pas problematisch als je die singleton door je hele code laat propageren, er is m.i. weinig mis met een connection factory die toevallig onder water altijd dezelfde instance teruggeeft.

[Solarsparc]

Er is trouwens nog een opmerking die ik wil maken: kijk ook eens goed naar een framework, in plaats van dit soort dingen allemaal zelf te willen doen.
Ik zat mij te bedenken waarom ik zo moest nadenken over deze kwestie, maar dat komt omdat ik het misschien al wel jaren niet meer zelf heb gedaan, heb al die tijd hoofdzakelijk frameworks gebruikt die ervoor zorgen dat je je met die dingen niet bezig hoeft te houden.
Voor php is bijv. Laravel een goed framework.

[Hydra]

Lees je eens in over Dependency Injection / Inversion of Control. Het idee hierachter is dat in plaats van dat je aan elke factory een connectie geeft, je dit door een DI library laat afhandelen en die dependency laat 'injecteren'. Dit heeft als voordeel dat je niet als je later een keer een andere database wil gebruiken dat 'uitdelen' van connecties overal aan moet passen. Daarnaast maakt het het makkelijker te unittesten tegen een mock-database.

Zelf werk ik niet met PHP maar met wat googlen op "PHP Dependency Injection" kom je een heel eind.

[krvabo]

Solarsparc schreef op donderdag 03 april 2014 @ 22:11:
Er is trouwens nog een opmerking die ik wil maken: kijk ook eens goed naar een framework, in plaats van dit soort dingen allemaal zelf te willen doen.
Ik zat mij te bedenken waarom ik zo moest nadenken over deze kwestie, maar dat komt omdat ik het misschien al wel jaren niet meer zelf heb gedaan, heb al die tijd hoofdzakelijk frameworks gebruikt die ervoor zorgen dat je je met die dingen niet bezig hoeft te houden.
Voor php is bijv. Laravel een goed framework.

Hoewel ik niets tegen frameworks heb kan ik moeilijk zeggen dat het de heilige graal is. Het is absoluut niet verkeerd om te weten wat er nou eigenlijk gebeurt met je code, in plaats van te denken dat alles perfect gaat. Als je dan een keer een project krijgt waarbij echte performance nodig is (high traffic met relatief laag budget, of applicaties waar vertragingen er toe doen) dan werk je ook niet met zulke pakketten.


Het (door 'Cartman!') aanraden van Doctrine is als tegen iemand zeggen dat hij een vlammenwerper kan gebruiken om die spin op z'n plafond weg te halen. Ja, het werkt, maar je wil het gewoon niet voor zoiets simpels.

Wat de vraag van de TS betreft is het helemaal niet slecht om een singleton te hebben in je database class van je applicatie. Zodra er in de specificaties staat dat er gecommuniceerd moet worden met meerdere databases dan kun je er vanaf het begin af aan rekening mee houden. Staat het niet in de specificaties dan is het 99.99% zeker dat het ook nooit hoeft. En in de rest van de gevallen kun je met een paar extra regels er voor zorgen dat je jouw singleton pattern kunt omzeilen en een losse instantie aan kan maken van je database class. Geen probleem dus.

[Barryvdh]

Als alternatief voor Doctrine of voor Laravel helemaal gebruiken, kan je ook Eloquent ('ActiveRecord style ORM' dat gebruikt wordt door Laravel) los gebruiken in je project: https://github.com/illuminate/database
Dat deed voor mij eigenlijk precies wat ik wou doen meestal.

PHP:

class User extends Illuminate\Database\Eloquent\Model {}

$users = User::where('votes', '>', 1)->get();
$user = User::find($id);
echo $user->name;
$user->votes++;
$user->save();

Overigens kan kan dat ook op dezelfde manier als jouw voorbeeld ongeveer:

PHP:

class User 
{ 
    public $Firstname; 
    public $Lastname; 

    public function Save() 
    { 
        $db = Capsule::connection();
        $db2 = Capsule::connection('other-connection-name');

        // query opbouwen en verwerken. 
    } 
}

Dus je zou ook eens kijken wat andere ORM's doen, als het pet perse zelf wil doen. In plaats van GetInstance() zou je ook meerdere connecties in je DB class kunnen opslaan, en dus een GetConnection($name) doen om een bepaalde connectie te krijgen.

[Lethalis]

Kun je trouwens niet gewoon connection pooling gebruiken?

Dan hoef je de verbinding niet vast te houden en kom je ook niet in de knoop met meerdere threads die dezelfde verbinding gebruiken.

Ik werk vooral aan ASP.NET applicaties en daarbij hou ik dus geen verbindingen vast. Ik zorg er alleen voor dat ik makkelijk bij de connection string kan komen (dat is dan vaak een static property van een AppConfig class bij mij die uit de web.config wordt gelezen) en maak simpelweg een verbinding als ik die nodig heb. Deze wordt dan dus uit de connection pool gehaald ipv opnieuw opgebouwd.

Als ik niet afhankelijk wil zijn van allerlei dingen, werk ik vaak met een "context" class. Deze bevat dan bijvoorbeeld de connection string, de ingelogde gebruiker, in feite alles dat ik meestal nodig heb in een business class.

Mijn business classes krijgen dan de context class mee als ze iets moeten doen.

Ik kan dus een AppContext class hebben, die door een Boekhouding class wordt gebruikt, die weer een GetOpenstaandePosten heeft bijvoorbeeld.

Een Singleton gebruik ik eigenlijk bijna nooit. Want een singleton moet je alleen gebruiken voor iets waar werkelijk maar 1 instantie van mag bestaan en nooit meer dan 1. Zelfs de constructor mag dan niet public zijn.

[ Voor 139% gewijzigd door Lethalis op 04-04-2014 14:22 ]

[drm]

krvabo:
Het (door 'Cartman!') aanraden van Doctrine is als tegen iemand zeggen dat hij een vlammenwerper kan gebruiken om die spin op z'n plafond weg te halen. Ja, het werkt, maar je wil het gewoon niet voor zoiets simpels.

"Kijk eens naar ...." kun je ook interpreteren als: duik eens in de source code van.... Dat kan in het geval van Doctrine wel heel erg leerzaam zijn, want het zit wel degelijk in elkaar. Het idee van Doctrine 2 is precies dat je domain classes niks weten van hun persistence, tenzij je dat zelf expliciet doet. En dat is wel een goed uitgangspunt voor het opzetten van een domain driven design.

Wat de vraag van de TS betreft is het helemaal niet slecht om een singleton te hebben in je database class van je applicatie. Zodra er in de specificaties staat dat er gecommuniceerd moet worden met meerdere databases dan kun je er vanaf het begin af aan rekening mee houden. Staat het niet in de specificaties dan is het 99.99% zeker dat het ook nooit hoeft. En in de rest van de gevallen kun je met een paar extra regels er voor zorgen dat je jouw singleton pattern kunt omzeilen en een losse instantie aan kan maken van je database class. Geen probleem dus.

Jij hebt duidelijk nog nooit een singleton pattern ergens uit hoeven refactoren. Dat is echt wel een probleem. Voor dat soort dingen kun je veel beter een DI container gebruiken. Dat is namelijk echt flexibel, en niet te vergeten makkelijk te unittesten.

[Cartman!]

krvabo schreef op donderdag 03 april 2014 @ 23:39:
[...]
Het (door 'Cartman!') aanraden van Doctrine is als tegen iemand zeggen dat hij een vlammenwerper kan gebruiken om die spin op z'n plafond weg te halen. Ja, het werkt, maar je wil het gewoon niet voor zoiets simpels.

Oneens, Doctrine is relatief simpel op te pakken en het niet zelf te hoeven bouwen scheelt je een hele hoop gedoe en alle problemen die je kunt tegenkomen hebben zij allemaal voor je opgelost. De TS loopt dusdanig tegen grenzen aan die je niet meer zelf moet gaan zitten op te lossen, waarom moeilijk doen? Het zelf bouwen van dingen ben ik sinds Composer vrijwel compleet vanaf gestapt en het bevalt fantastisch. Dingen zelf willen bouwen from scratch blijft een trekje van PHP developers imo.

En singleton is een anti-pattern imo, drm geeft ook al aan dat het drama is om een singleton om te bouwen naar iets anders. Voor dependency injection kun je eens kijken naar Pimple, die is echt zo simpel in gebruik dat je afvroeg waarom je het niet eerder gebruikte (zelfde geldt voor Doctrine ook ).

[ Voor 15% gewijzigd door Cartman! op 05-04-2014 16:26 ]

[The Eagle]

Waarom een DB connectie in 's hemelsnaam in de applicatie afvangen?
Aangezien de applicatie toch DB specifiek zal zijn, de logica daar stoppen waar ie hoort. Ergo: in de DB dus.
Gewoon een stored procedure op DB niveau maken die je aan kunt roepen en die de DB connectie naar een externe Db voor je afhandelt.

[krvabo]

drm schreef op zaterdag 05 april 2014 @ 12:22:
[...]

"Kijk eens naar ...." kun je ook interpreteren als: duik eens in de source code van.... Dat kan in het geval van Doctrine wel heel erg leerzaam zijn, want het zit wel degelijk in elkaar. Het idee van Doctrine 2 is precies dat je domain classes niks weten van hun persistence, tenzij je dat zelf expliciet doet. En dat is wel een goed uitgangspunt voor het opzetten van een domain driven design.

Hm dat ben ik met je eens, en ja, Doctrine zit an sich prima in elkaar. Zover ik er kennis van heb dan (pas enkele weken ervaring mee), maar dat was uiteraard niet zo bedoeld in de tekst die ik aanhaalde. Al ben ik echter geen fan van doctrine, maar dat kan zijn omdat ik vastgeroest ben in een manier van werken die ik al zeer lang aanhoud Niet dat het me slecht lijkt; ik vind het gewoon geen fijne manier van werken.

[...]
Jij hebt duidelijk nog nooit een singleton pattern ergens uit hoeven refactoren. Dat is echt wel een probleem. Voor dat soort dingen kun je veel beter een DI container gebruiken. Dat is namelijk echt flexibel, en niet te vergeten makkelijk te unittesten.

Nouja, ik heb wel vaker om een singleton pattern heengewerkt, maar niet structureel gerefactord nee. Ik zie ook niet direct in waarom je dat zou doen, in plaats van er omheen werken. Bij bijna alle systemen staat van te voren vast of je één of meerdere databases aan zou moeten spreken. Als je achteraf nog een extra connectie toe moet voegen (zeg 'jaren later') dan is het vaak een beperkte connectie; dat wil zeggen: beperkte functionaliteit. In zo'n geval is het imho prima daar omheen te werken. Dan wel door het mogelijk te maken de singleton te omzeilen (een beetje een hack), ofwel een losse connectie op te zetten binnen de functionaliteit / class zelf (mits de scope beperkt is).

Het ligt er gewoon heel erg aan wat de precieze omstandigheden zijn. Soms zal het inderdaad zo zijn dat je de hele singleton moet refactoren (al zal dit absoluut niet vaak zijn), maar in het overgrote merendeel van de gevallen zal vooraf bekend zijn dat je slechts één connectie (of juist meerdere) nodig hebt.

Vooraf het singleton pattern in een database class / connectie aanvallen vind ik onzinnig. Ja, uiteraard kun je er allerlei design patterns tegenaan gooien, of abstractielagen en DAL / ORM en weet ik het allemaal nog meer niet om het zo enterprise-y te maken als je maar kunt, maar dat maakt het imho niet overzichtelijker. Maar misschien ben ik wel gewoon bevooroordeeld

Cartman! schreef op zaterdag 05 april 2014 @ 16:23:
[...]

Oneens, Doctrine is relatief simpel op te pakken en het niet zelf te hoeven bouwen scheelt je een hele hoop gedoe en alle problemen die je kunt tegenkomen hebben zij allemaal voor je opgelost. De TS loopt dusdanig tegen grenzen aan die je niet meer zelf moet gaan zitten op te lossen, waarom moeilijk doen? Het zelf bouwen van dingen ben ik sinds Composer vrijwel compleet vanaf gestapt en het bevalt fantastisch. Dingen zelf willen bouwen from scratch blijft een trekje van PHP developers imo.

Mijn ervaring met Doctrine viel samen met mijn eerste ervaring van Symfony2 in een complex (overgenomen) project. Dit heeft er voor gezorgd dat ik beiden extreem frustrerend vond. Hetzelfde geldt voor composer omdat als ik iets moet uitvoeren via de command line ik al afhaak (zeker op een liveomgeving).
Uiteraard -moet- je het niet zelf doen, je kunt het zelf doen omdat je bijvoorbeeld een betere performance wilt hebben. Doctrine zorgt voor een behoorlijke vertraging, en tenzij je behoorlijke resources tot je beschikking hebt is het mogelijk slimmer om zelf zo raw mogelijk te schrijven. Het is puur een afweging tussen "gemak" en performance, net als heel veel softwareontwikkelingsprincipes.

En singleton is een anti-pattern imo, drm geeft ook al aan dat het drama is om een singleton om te bouwen naar iets anders. Voor dependency injection kun je eens kijken naar Pimple, die is echt zo simpel in gebruik dat je afvroeg waarom je het niet eerder gebruikte (zelfde geldt voor Doctrine ook ).

Dat singleton slecht is wordt al overal en nergens geroepen sinds de jaren 90, en tot op zekere hoogte klopt dat. Er zijn zeker zeer goede argumenten tegen het gebruik van een singleton pattern. Ik zeg alleen dat het gebruik van het singleton pattern _binnen php_ _binnen de databaseclass_ _als duidelijk is dat er altijd maar één databaseconnectie is_ imho best kan. Ja, het gebruik van een builder / dependency injection / factory is 'netter', maar ook complexer en is op dat moment imho meer 'omdat het kan' dan dat het daadwerkelijk nuttig is.

[drm]

krvabo:
Dat singleton slecht is wordt al overal en nergens geroepen sinds de jaren 90, en tot op zekere hoogte klopt dat. Er zijn zeker zeer goede argumenten tegen het gebruik van een singleton pattern. Ik zeg alleen dat het gebruik van het singleton pattern _binnen php_ _binnen de databaseclass_ _als duidelijk is dat er altijd maar één databaseconnectie is_ imho best kan.

Daar heb je op zich wel gelijk in, maar er zijn hele goede redenen voor het feit dat je een singleton moet mijden en dat je daar ook beter vroeg dan laat achter kan komen.

Allereerst omdat een singleton eigenlijk een glorified global is. Je kunt ineens overal en nergens naar die connectie gaan verwijzen, zonder dat het een expliciete dependency is. Dat levert 2 problemen op:

1. Je code wordt er ondoorzichtig van
2. Je (as in: de programmeur) wordt er lui van

Het introduceren van een expliciete dependency en de dan zo goed als onvermijdelijke noodzaak van een DI container, levert daarentegen drie voor-de-hand-liggende voordelen op:

1. De dependencies zijn helder: elk stuk code dat een database connectie nodig heeft (expliciet dependent is) declareert dat
2. Het helpt om de persistence laag los te zien van je business (domain) logic
3. Het is veel eenvoudiger om er tests voor te schrijven

Dat helpt vervolgens weer om beter na te denken over dependencies in het algemeen, en mijn nederige mening is dat het principe dat boven alle andere staat in software design (maar ook in heel veel andere dingen) is Separation of Concerns. Dat moet te allen tijde hoog op de agenda staan. Simpelweg omdat het je een betere developer, software architect, consultant, enz. maakt, om maar niet te spreken van het bestaansrecht van OO patterns in het algemeen.

Het is niet voor niks dat singletons lastig te testen zijn. Dat komt omdat het een antipattern is wat feitelijk een paar OO features misbruikt om OO te omzeilen. Met andere woorden: Depency Injection helpt je om beter OO te redeneren, en dat is in het algemeen goed. Al is het alleen al voor je ontwikkeling.

Verder is een singleton voor databases not done omdat het het gebruik van meerdere connecties t.b.v replication vrijwel onmogelijk maakt. Het argument "dat zal mij niet overkomen" is dan niet zo'n hele beste, vind ik. Er wordt van elke developer verwacht dat hij de consequenties van zijn keuzes (min of meer) overziet. Als er iets belangrijk is voor databases is het wel schaalbaarheid. En het introduceren van een DI container daarvoor is veel simpeler dan het lijkt. Kijk voor de grap eens naar Pimple voor een idee hoe het ook simpel (haha dat rijmt) kan.

Het argument dat het te complex of "overkill" zou zijn is wat mij betreft onzin omdat het dat gewoon niet is. Overkill is het niet omdat het ten minste gelijkwaardig is, en uiteindelijk waarschijnlijk zelfs efficienter dan een singleton. Te complex is het niet, omdat dat een kwestie is van je eigen capaciteiten, oftewel: jezelf (willen) ontwikkelen.

[Douweegbertje]

Wat is het probleem om te beginnen met je DB connectie? Ik heb een tijdje CodeIgniter gebruikt met 2 databases (mysql en mssql). Ik heb er niet eens zo diep over nagedacht, maar voor mij was het nogal simpel.
Ten eerste lade ik gewoon de basis lib in de construct en vervolgens riep ik de DB aan die ik wilde.

PHP:

$mssql = $this->load->db('mssql');
$mysql = $this->load->db('mysql');

$this->mssql->query('.........');
//of
$this->mysql ->select('.......');
// of elk ander command wat in de lib zat...

[4Real]

Aardig wat antwoorden en een berg informatie Even een korte vraag, ik ben nog bezig om het hele DI concept eigen te maken. Op het moment ben ik met Pimple aan het kloten om een beetje door te krijgen hoe het werkt, maar wat je nu krijgt is dat je deze container steeds in je controller wilt krijgen om er gebruik van te maken. Hoe kun je dit het beste aanpakken? Een variabel maken in mijn FrontController waar de DI container inhangt?

[drm]

Maak je front controller een service in je DI container, en laat hem afhankelijk zijn van de container zelf. Het is niet echt good practice, per se, maar het lost je probleem wel op.

Dus iets van:

code:

$container['front'] = $container->share(function($c) {
    return new FrontController($c);
});

// ...

$container['front']->handleGet($_GET);

Het mooie hiervan is dat je al heel snel aan leert voelen wanneer iets op zijn beurt ook weer een service zou kunnen zijn (bijvoorbeeld de request)

In Silex wordt dat concept verder uitgewerkt en vind je een mooie mix tussen eenvoudige DI en nette OO en services. Die zou je er naast kunnen houden als je het concept je eigen wilt maken.