php - What are the advantages to passing a global DB connection into each function of a model? -

i working older code base passed db connection functions in each class of models. db connection created global , passed everywhere in application:

$user = new user(); $user->loadbyid($db, $userid); 

what advantages doing vs single connection entire model inherits similar way frameworks work?

any insight helpful.

full disclosure: asked question way because how @ work. don't pass around db connection. trying find proponent of method see if mind can changed. why tried sway discussion pro side of conversation without being blocked bad question. , worked. didn't banned, great stackoverflow community didn't let me down. appears i'm not out in left field how think issue.

the main advantage is: it's easier. in, it's simplest thing do, because result, you have no application architecture. you're grasping @ things everywhere , anywhere because have no idea how them otherwise, , makes poor maintainability. guess happens 5 years down line sort of codebase? massive legacy technical debt, , it's developers aren't using object oriented programming - more shoving procedural code in classes.

i'm not going bother explaining global state, because there's fantastic answer exists on programmers. small excerpt:

very briefly, makes program state unpredictable.

to elaborate, imagine have couple of objects both use same global variable. assuming you're not using source of randomness anywhere within either module, output of particular method can predicted (and therefore tested) if state of system known before execute method.

however, if method in 1 of objects triggers side effect changes value of shared global state, no longer know starting state when execute method in other object. can no longer predict output you'll when execute method, , therefore can't test it.

you'll find developers purely out of laziness or lack of knowledge / understanding of basic concepts of solid. if access global state (like database), beautiful, isolated class writing theoretically can handed off other developer, , tested in it's own right, coupled object somewhere off in clouds.

as above, you're making liar of object api. each object should, via it's constructor / method signatures, specify exactly required external objects requires function. allows:

• your object have definitive api it's usage
• future developers can see required object function constructor / method signatures
• everything passed in via dependency injection (the posh word passing in parameters, basically), can 'mocked out' testability
• developers don't need read through code find out other objects required, because of point 2
• you aren't accessing can changed else, somewhere else, , make debugging nightmare

your code should not brittle. should confident in making changes somewhere in massive codebase, without worrying breaking somewhere else. unit tests cover this. highly recommend reading the clean coder elaborates on of these concepts.

almado has picture of image singletons, objects return single instance of object, database or logger. if request new database it, either new 1 or 1 exists. in traditional request / response / dead context, this unecessary. if you're having very long-running process, maybe might necessary, in other languages, general rule of thumb in php; unless you're running php web socket server or similar, di better way go maintainability.

this exactly same calling staticobject::database, again - can accessed anywhere.

this post on singletons in php, , how they're not @ needed - post has lot of useful links in further down.

basically - don't lazy , grasp solid. there's reason exists, , it's not php, either. main reason people because don't know better , it's easier, , easier isn't best way.

---

also, few additional clarifications. don't have "models". have a model, layer. massive misinterpretation of 'mvc', don't have in php ('classical mvc'). have separation of concerns , that's it.

• your "models" likely, services, domain objects, entities. more info on model is

• your user should not know database. should entity. active record pattern not way forward. take @ datamapper. repository use database object , return array of user objects. contextually well, user having access database makes no sense.

• most frameworks do not work having access database in entities - isn't php 4 more, it's progressed lot since ;-) highly recommend moving away cakephp (it's not mvc in way) , take @ framework symfony, still has it's flaws - knowing flaws of chosen framework important