What is the best practice for adding persistence to an MVC model?
What is the best practice for adding persistence to an MVC model?
am 27.10.2009 07:27:07 von Eric Bauman
I'm in the process of implementing an ultra-light MVC framework in PHP.
It seems to be a common opinion that the loading of data from a
database, file etc. should be independent of the Model, and I agree.
What I'm unsure of is the best way to link this "data layer" into MVC.
I've considered a few options:
*Datastore interacts with Model*
//controller
public function update()
{
$model = $this->loadModel('foo');
$data = $this->loadDataStore('foo', $model);
$data->loadBar(9); //loads data and populates Model
$model->setBar('bar');
$data->save(); //reads data from Model and saves
}
*Controller mediates between Model and Datastore*
Seems a bit verbose and requires the model to know that a datastore exists.
//controller
public function update()
{
$model = $this->loadModel('foo');
$data = $this->loadDataStore('foo');
$model->setDataStore($data);
$model->getDataStore->loadBar(9); //loads data and populates Model
$model->setBar('bar');
$model->getDataStore->save(); //reads data from Model and saves
}
*Datastore extends Model*
What happens if we want to save a Model extending a database datastore
to a flatfile datastore?
//controller
public function update()
{
$model = $this->loadHybrid('foo'); //get_class == Datastore_Database
$model->loadBar(9); //loads data and populates
$model->setBar('bar');
$model->save(); //saves
}
*Model extends datastore*
This allows for Model portability, but it seems wrong to extend like
this. Further, the datastore cannot make use of any of the Model's methods.
//controller extends model
public function update()
{
$model = $this->loadHybrid('foo'); //get_class == Model
$model->loadBar(9); //loads data and populates
$model->setBar('bar');
$model->save(); //saves
}
Any input on the "best" option - or alternative - would be most appreciated.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: What is the best practice for adding persistence to an MVC model?
am 27.10.2009 11:15:33 von Tony Marston
It sounds like you need a combination of MVC and the 3 Tier Architecture.
They are not the same thing, for reasons described at
http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq26
I have combined both these patterns in the Radicore framework - take a look
at http://www.radicore.org/. If you don't like the idea of downloading a
large framework there is a small sample application described in
http://www.tonymarston.net/php-mysql/sample-application.html which is
available for download.
Basically you need to have code in every business object (every object in
the Business layer) which communicates with a separate object for all its
database access. This is known as a Data Access Object as it exists in the
Data Access layer.
If you do it right it will be possible to have a separate DAO for each DBMS
so that you can switch between one database engine and another by simply
changing a single configuration variable. In my own framework I have
implemented DAOs for MySQL, PostgreSQL and Oracle.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
"Eric Bauman" wrote in message
news:B9.45.36627.EB296EA4@pb1.pair.com...
> I'm in the process of implementing an ultra-light MVC framework in PHP. It
> seems to be a common opinion that the loading of data from a database,
> file etc. should be independent of the Model, and I agree. What I'm unsure
> of is the best way to link this "data layer" into MVC.
>
> I've considered a few options:
>
> *Datastore interacts with Model*
>
> //controller
> public function update()
> {
>
> $model = $this->loadModel('foo');
> $data = $this->loadDataStore('foo', $model);
>
> $data->loadBar(9); //loads data and populates Model
> $model->setBar('bar');
> $data->save(); //reads data from Model and saves
>
> }
>
> *Controller mediates between Model and Datastore*
>
> Seems a bit verbose and requires the model to know that a datastore
> exists.
>
> //controller
> public function update()
> {
>
> $model = $this->loadModel('foo');
> $data = $this->loadDataStore('foo');
>
> $model->setDataStore($data);
>
> $model->getDataStore->loadBar(9); //loads data and populates Model
> $model->setBar('bar');
> $model->getDataStore->save(); //reads data from Model and saves
>
> }
>
> *Datastore extends Model*
>
> What happens if we want to save a Model extending a database datastore to
> a flatfile datastore?
>
> //controller
> public function update()
> {
>
> $model = $this->loadHybrid('foo'); //get_class == Datastore_Database
>
> $model->loadBar(9); //loads data and populates
> $model->setBar('bar');
> $model->save(); //saves
>
> }
>
> *Model extends datastore*
>
> This allows for Model portability, but it seems wrong to extend like this.
> Further, the datastore cannot make use of any of the Model's methods.
>
> //controller extends model
> public function update()
> {
>
> $model = $this->loadHybrid('foo'); //get_class == Model
>
> $model->loadBar(9); //loads data and populates
> $model->setBar('bar');
> $model->save(); //saves
>
> }
>
>
>
> Any input on the "best" option - or alternative - would be most
> appreciated.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: What is the best practice for adding persistence to anMVC model?
am 27.10.2009 12:14:27 von Mert Oztekin
SGkgRXJpYywNCg0KSU1PLCBjb250cm9sbGVycyBzaG91bGRudCBiZSByZXNw b25zaWJsZSBmb3Ig
aW50ZXJhY3RpbmcgbW9kZWxzIGFuZCBkYXRhc3RvcmVyZXMuIENvbnRyb2xs ZXJzIG1pZ2h0IG9u
bHkgY2hhbmdlIHRoZSBkYXRhc3RvcmUgY2xhc3Mgb2YgYSBtb2RlbC4NCg0K WW91IG1heSB1c2Ug
eW91ciBtb2RlbHMgaW4gbG90cyBvZiBjb250cm9sbGVyIGZ1bmN0aW9ucy4g RGVmaW5pbmcgZGF0
YXN0b3JlIGluIGFsbCBjb250cm9sbGVycyBzZWVtcyBub3QgYSBnb29kIHBy YWN0aWNlLiAodG9v
IG11Y2ggdW5uZWNjZXNzYXJ5IGNvZGVzIHdyaXR0ZW4pDQoNCkEgc2ltcGxl IGV4YW1wbGUNCg0K
Ly9jb250cm9sbGVyDQpQdWJsaWMgZnVuY3Rpb24gZG9JdENvbnRyb2xsZXIo KQ0Kew0KICAgICAg
ICAkdXNlciA9IG5ldyB1c2VyKCk7DQogICAgICAgIC8vICR1c2VyLT5zZXRE YXRhU3RvcmVyKG5l
dyBhbm90aGVyRGF0YVN0b3JlcigpKTsgICAvLyB0aGlzIGlzIG9wdGlvbmFs IGlmIHlvdSB3YW50
IHRvIGNoYW5nZSBtb2RlbHMgZGF0YXN0b3Jlcg0KICAgICAgICAkdXNlci0+ bG9hZFVzZXJGcm9t
SWQoMSk7DQp9DQoNCi8vIG1vZGVsDQpDbGFzcyB1c2VyDQp7DQogICAgICAg IFByb3RlY3RlZCAk
X2RhdGFTdG9yZXIgPSBudWxsOw0KDQogICAgICAgIFB1YmxpYyBmdW5jdGlv biBsb2FkVXNlckZy
b21JZCgkaWQgPSAwKQ0KICAgICAgICB7DQogICAgICAgICAgICAgICAgLy8g Y29kZXMgY29kZXMg
Y29kZXMNCiAgICAgICAgICAgICAgICAkcmVzdWx0ID0gICAgICAgJHRoaXMt PmdldERhdGFTdG9y
ZXIoKS0+cXVlcnkoInNlbGVjdCAuLi4uLiIpOw0KICAgICAgICAgICAgICAg IC8vIGNvZGVzIGNv
ZGVzIGNvZGVzDQogICAgICAgIH0NCg0KICAgICAgICAvLyBjb2RlcyBjb2Rl cyBjb2Rlcw0KICAg
ICAgICBQdWJsaWMgZnVuY3Rpb24gZ2V0RGF0YVN0b3JlcigpDQogICAgICAg IHsNCiAgICAgICAg
ICAgICAgICBpZihudWxsID09ICR0aGlzLT5fZGF0YVN0b3JlcikNCiAgICAg ICAgICAgICAgICAg
ICAgICAgICR0aGlzLT5fZGF0YVN0b3JlciA9IG5ldyBteVZlcnlCZXN0RGF0 YVN0b3JlcigpOw0K
ICAgICAgICAgICAgICAgIHJldHVybiAkdGhpcy0+X2RhdGFTdG9yZXI7DQog ICAgICAgIH0NCg0K
ICAgICAgICBQdWJsaWMgZnVuY3Rpb24gc2V0RGF0YVN0b3JlcigkbmV3U3Rv cmVyKQ0KICAgICAg
ICB7DQogICAgICAgICAgICAgICAgJHRoaXMtPl9kYXRhU3RvcmVyID0gJG5l d1N0b3JlcjsNCiAg
ICAgICAgfQ0KfQ0KDQoNCkhvcGUgaXQgd2lsbCBiZSB1c2VmdWxsIGFuZCB1 bmRlcnN0YW5kYWJs
ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXJpYyBC YXVtYW4gW21haWx0
bzpiYXVtYW5lQGxpdmVqb3VybmFsLmRrXQ0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAyNywgMjAw
OSA4OjI3IEFNDQpUbzogcGhwLWdlbmVyYWxAbGlzdHMucGhwLm5ldA0KU3Vi amVjdDogW1BIUF0g
V2hhdCBpcyB0aGUgYmVzdCBwcmFjdGljZSBmb3IgYWRkaW5nIHBlcnNpc3Rl bmNlIHRvIGFuIE1W
QyBtb2RlbD8NCg0KSSdtIGluIHRoZSBwcm9jZXNzIG9mIGltcGxlbWVudGlu ZyBhbiB1bHRyYS1s
aWdodCBNVkMgZnJhbWV3b3JrIGluIFBIUC4NCkl0IHNlZW1zIHRvIGJlIGEg Y29tbW9uIG9waW5p
b24gdGhhdCB0aGUgbG9hZGluZyBvZiBkYXRhIGZyb20gYQ0KZGF0YWJhc2Us IGZpbGUgZXRjLiBz
aG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgdGhlIE1vZGVsLCBhbmQgSSBhZ3Jl ZS4NCldoYXQgSSdt
IHVuc3VyZSBvZiBpcyB0aGUgYmVzdCB3YXkgdG8gbGluayB0aGlzICJkYXRh IGxheWVyIiBpbnRv
IE1WQy4NCg0KSSd2ZSBjb25zaWRlcmVkIGEgZmV3IG9wdGlvbnM6DQoNCipE YXRhc3RvcmUgaW50
ZXJhY3RzIHdpdGggTW9kZWwqDQoNCi8vY29udHJvbGxlcg0KcHVibGljIGZ1 bmN0aW9uIHVwZGF0
ZSgpDQp7DQoNCiAgJG1vZGVsID0gJHRoaXMtPmxvYWRNb2RlbCgnZm9vJyk7 DQogICRkYXRhID0g
JHRoaXMtPmxvYWREYXRhU3RvcmUoJ2ZvbycsICRtb2RlbCk7DQoNCiAgJGRh dGEtPmxvYWRCYXIo
OSk7IC8vbG9hZHMgZGF0YSBhbmQgcG9wdWxhdGVzIE1vZGVsDQogICRtb2Rl bC0+c2V0QmFyKCdi
YXInKTsNCiAgJGRhdGEtPnNhdmUoKTsgLy9yZWFkcyBkYXRhIGZyb20gTW9k ZWwgYW5kIHNhdmVz
DQoNCn0NCg0KKkNvbnRyb2xsZXIgbWVkaWF0ZXMgYmV0d2VlbiBNb2RlbCBh bmQgRGF0YXN0b3Jl
Kg0KDQpTZWVtcyBhIGJpdCB2ZXJib3NlIGFuZCByZXF1aXJlcyB0aGUgbW9k ZWwgdG8ga25vdyB0
aGF0IGEgZGF0YXN0b3JlIGV4aXN0cy4NCg0KLy9jb250cm9sbGVyDQpwdWJs aWMgZnVuY3Rpb24g
dXBkYXRlKCkNCnsNCg0KICAkbW9kZWwgPSAkdGhpcy0+bG9hZE1vZGVsKCdm b28nKTsNCiAgJGRh
dGEgPSAkdGhpcy0+bG9hZERhdGFTdG9yZSgnZm9vJyk7DQoNCiAgJG1vZGVs LT5zZXREYXRhU3Rv
cmUoJGRhdGEpOw0KDQogICRtb2RlbC0+Z2V0RGF0YVN0b3JlLT5sb2FkQmFy KDkpOyAvL2xvYWRz
IGRhdGEgYW5kIHBvcHVsYXRlcyBNb2RlbA0KICAkbW9kZWwtPnNldEJhcign YmFyJyk7DQogICRt
b2RlbC0+Z2V0RGF0YVN0b3JlLT5zYXZlKCk7IC8vcmVhZHMgZGF0YSBmcm9t IE1vZGVsIGFuZCBz
YXZlcw0KDQp9DQoNCipEYXRhc3RvcmUgZXh0ZW5kcyBNb2RlbCoNCg0KV2hh dCBoYXBwZW5zIGlm
IHdlIHdhbnQgdG8gc2F2ZSBhIE1vZGVsIGV4dGVuZGluZyBhIGRhdGFiYXNl IGRhdGFzdG9yZQ0K
dG8gYSBmbGF0ZmlsZSBkYXRhc3RvcmU/DQoNCi8vY29udHJvbGxlcg0KcHVi bGljIGZ1bmN0aW9u
IHVwZGF0ZSgpDQp7DQoNCiAgJG1vZGVsID0gJHRoaXMtPmxvYWRIeWJyaWQo J2ZvbycpOyAvL2dl
dF9jbGFzcyA9PSBEYXRhc3RvcmVfRGF0YWJhc2UNCg0KICAkbW9kZWwtPmxv YWRCYXIoOSk7IC8v
bG9hZHMgZGF0YSBhbmQgcG9wdWxhdGVzDQogICRtb2RlbC0+c2V0QmFyKCdi YXInKTsNCiAgJG1v
ZGVsLT5zYXZlKCk7IC8vc2F2ZXMNCg0KfQ0KDQoqTW9kZWwgZXh0ZW5kcyBk YXRhc3RvcmUqDQoN
ClRoaXMgYWxsb3dzIGZvciBNb2RlbCBwb3J0YWJpbGl0eSwgYnV0IGl0IHNl ZW1zIHdyb25nIHRv
IGV4dGVuZCBsaWtlDQp0aGlzLiBGdXJ0aGVyLCB0aGUgZGF0YXN0b3JlIGNh bm5vdCBtYWtlIHVz
ZSBvZiBhbnkgb2YgdGhlIE1vZGVsJ3MgbWV0aG9kcy4NCg0KLy9jb250cm9s bGVyIGV4dGVuZHMg
bW9kZWwNCnB1YmxpYyBmdW5jdGlvbiB1cGRhdGUoKQ0Kew0KDQogICRtb2Rl bCA9ICR0aGlzLT5s
b2FkSHlicmlkKCdmb28nKTsgIC8vZ2V0X2NsYXNzID09IE1vZGVsDQoNCiAg JG1vZGVsLT5sb2Fk
QmFyKDkpOyAvL2xvYWRzIGRhdGEgYW5kIHBvcHVsYXRlcw0KICAkbW9kZWwt PnNldEJhcignYmFy
Jyk7DQogICRtb2RlbC0+c2F2ZSgpOyAvL3NhdmVzDQoNCn0NCg0KDQoNCkFu eSBpbnB1dCBvbiB0
aGUgImJlc3QiIG9wdGlvbiAtIG9yIGFsdGVybmF0aXZlIC0gd291bGQgYmUg bW9zdCBhcHByZWNp
YXRlZC4NCg0KLS0NClBIUCBHZW5lcmFsIE1haWxpbmcgTGlzdCAoaHR0cDov L3d3dy5waHAubmV0
LykNClRvIHVuc3Vic2NyaWJlLCB2aXNpdDogaHR0cDovL3d3dy5waHAubmV0 L3Vuc3ViLnBocA0K
DQoNCkJ1IG1lc2FqIHZlIGVrbGVyaSwgbWVzYWpkYSBnw7ZuZGVyaWxkacSf aSBiZWxpcnRpbGVu
IGtpxZ9pL2tpxZ9pbGVyZSDDtnplbGRpciB2ZSBnaXpsaWRpci4gU2l6ZSB5 YW5sxLHFn2zEsWts
YSB1bGHFn23EscWfc2EgbMO8dGZlbiBnw7ZuZGVyZW4ga2lzaXlpIGJpbGdp bGVuZGlyaW5peiB2
ZSBtZXNhasSxIHNpc3RlbWluaXpkZW4gc2lsaW5pei4gTWVzYWogdmUgZWts ZXJpbmluIGnDp2Vy
acSfaSBpbGUgaWxnaWxpIG9sYXJhayDFn2lya2V0aW1pemluIGhlcmhhbmdp IGJpciBodWt1a2kg
c29ydW1sdWx1xJ91IGJ1bHVubWFtYWt0YWTEsXIuIMWeaXJrZXRpbWl6IG1l c2FqxLFuIHZlIGJp
bGdpbGVyaW5pbiBzaXplIGRlxJ9pxZ9pa2xpxJ9lIHXEn3JheWFyYWsgdmV5 YSBnZcOnIHVsYcWf
bWFzxLFuZGFuLCBiw7x0w7xubMO8xJ/DvG7DvG4gdmUgZ2l6bGlsacSfaW5p biBrb3J1bmFtYW1h
c8SxbmRhbiwgdmlyw7xzIGnDp2VybWVzaW5kZW4gdmUgYmlsZ2lzYXlhciBz aXN0ZW1pbml6ZSB2
ZXJlYmlsZWNlxJ9pIGhlcmhhbmdpIGJpciB6YXJhcmRhbiBzb3J1bWx1IHR1 dHVsYW1hei4NCg0K
VGhpcyBtZXNzYWdlIGFuZCBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRl
ZCBmb3IgdGhlIGluZGl2aWR1YWwocykgc3RhdGVkIGluIHRoaXMgbWVzc2Fn ZS4gSWYgeW91IHJl
Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0 ZWx5IG5vdGlmeSB0
aGUgc2VuZGVyIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gT3Vy IGNvbXBhbnkgaGFz
IG5vIGxlZ2FsIHJlc3BvbnNpYmlsaXR5IGZvciB0aGUgY29udGVudHMgb2Yg dGhlIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cy4gT3VyIGNvbXBhbnkgc2hhbGwgaGF2ZSBu byBsaWFiaWxpdHkg
Zm9yIGFueSBjaGFuZ2VzIG9yIGxhdGUgcmVjZWl2aW5nLCBsb3NzIG9mIGlu dGVncml0eSBhbmQg
Y29uZmlkZW50aWFsaXR5LCB2aXJ1c2VzIGFuZCBhbnkgZGFtYWdlcyBjYXVz ZWQgaW4gYW55d2F5
IHRvIHlvdXIgY29tcHV0ZXIgc3lzdGVtLg0K
RE: What is the best practice for adding persistence to an MVC model?
am 27.10.2009 15:34:52 von David Murphy
--=======AVGMAIL-5C492469=======
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I take a different approach :
// In the MainHandler
Define('StorageClassName',"_MySQL");
Class UserController {
function __construct($objDataStore=3Dfalse){
if(!$objDataStore)
$this->DataStore =3D new instanceof($this).STORAGECLASSNAME ;
}
Function update(){
$data =3D $this->DataStore->Load("foo");
$data->Set("foo","bar");
$data->save;
}
This assumes your using DBO so the loaded foo object inherited the =
settings/methods from the DB Datastore.
Thus letting you passing a different datastore object or it builds =
one based on the model name and the storage type you set as a constant.
However it still links the two together so you can use $this calls to =
reference the DataStore of the Model layer.
David
> -----Original Message-----
> From: Mert Oztekin [mailto:moztekin@anadolusigorta.com.tr]
> Sent: Tuesday, October 27, 2009 6:14 AM
> To: 'Eric Bauman'; php-general@lists.php.net
> Subject: RE: [PHP] What is the best practice for adding persistence to =
an MVC
> model?
>=20
> Hi Eric,
>=20
> IMO, controllers shouldnt be responsible for interacting models and
> datastoreres. Controllers might only change the datastore class of a =
model.
>=20
> You may use your models in lots of controller functions. Defining =
datastore in
> all controllers seems not a good practice. (too much unneccessary =
codes
> written)
>=20
> A simple example
>=20
> //controller
> Public function doItController()
> {
> $user =3D new user();
> // $user->setDataStorer(new anotherDataStorer()); // this is =
optional if
> you want to change models datastorer
> $user->loadUserFromId(1);
> }
>=20
> // model
> Class user
> {
> Protected $_dataStorer =3D null;
>=20
> Public function loadUserFromId($id =3D 0)
> {
> // codes codes codes
> $result =3D =
$this->getDataStorer()->query("select .....");
> // codes codes codes
> }
>=20
> // codes codes codes
> Public function getDataStorer()
> {
> if(null == $this->_dataStorer)
> $this->_dataStorer =3D new =
myVeryBestDataStorer();
> return $this->_dataStorer;
> }
>=20
> Public function setDataStorer($newStorer)
> {
> $this->_dataStorer =3D $newStorer;
> }
> }
>=20
>=20
> Hope it will be usefull and understandable
>=20
> -----Original Message-----
> From: Eric Bauman [mailto:baumane@livejournal.dk]
> Sent: Tuesday, October 27, 2009 8:27 AM
> To: php-general@lists.php.net
> Subject: [PHP] What is the best practice for adding persistence to an =
MVC
> model?
>=20
> I'm in the process of implementing an ultra-light MVC framework in =
PHP.
> It seems to be a common opinion that the loading of data from a =
database,
> file etc. should be independent of the Model, and I agree.
> What I'm unsure of is the best way to link this "data layer" into MVC.
>=20
> I've considered a few options:
>=20
> *Datastore interacts with Model*
>=20
> //controller
> public function update()
> {
>=20
> $model =3D $this->loadModel('foo');
> $data =3D $this->loadDataStore('foo', $model);
>=20
> $data->loadBar(9); //loads data and populates Model
> $model->setBar('bar');
> $data->save(); //reads data from Model and saves
>=20
> }
>=20
> *Controller mediates between Model and Datastore*
>=20
> Seems a bit verbose and requires the model to know that a datastore =
exists.
>=20
> //controller
> public function update()
> {
>=20
> $model =3D $this->loadModel('foo');
> $data =3D $this->loadDataStore('foo');
>=20
> $model->setDataStore($data);
>=20
> $model->getDataStore->loadBar(9); //loads data and populates Model
> $model->setBar('bar');
> $model->getDataStore->save(); //reads data from Model and saves
>=20
> }
>=20
> *Datastore extends Model*
>=20
> What happens if we want to save a Model extending a database datastore =
to
> a flatfile datastore?
>=20
> //controller
> public function update()
> {
>=20
> $model =3D $this->loadHybrid('foo'); //get_class == =
Datastore_Database
>=20
> $model->loadBar(9); //loads data and populates
> $model->setBar('bar');
> $model->save(); //saves
>=20
> }
>=20
> *Model extends datastore*
>=20
> This allows for Model portability, but it seems wrong to extend like =
this.
> Further, the datastore cannot make use of any of the Model's methods.
>=20
> //controller extends model
> public function update()
> {
>=20
> $model =3D $this->loadHybrid('foo'); //get_class == Model
>=20
> $model->loadBar(9); //loads data and populates
> $model->setBar('bar');
> $model->save(); //saves
>=20
> }
>=20
>=20
>=20
> Any input on the "best" option - or alternative - would be most =
appreciated.
>=20
> --
> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php
>=20
>=20
> Bu mesaj ve ekleri, mesajda gönderildiÄi belirtilen =
kiÅi/kiÅilere özeldir ve
> gizlidir. Size yanlıÅlıkla ulaÅmıÅsa =
lütfen gönderen kisiyi bilgilendiriniz ve mesajı
> sisteminizden siliniz. Mesaj ve eklerinin içeriÄi ile ilgili =
olarak Åirketimizin
> herhangi bir hukuki sorumluluÄu bulunmamaktadır. =
Åirketimiz mesajın ve
> bilgilerinin size deÄiÅikliÄe uÄrayarak veya =
geç ulaÅmasından, =
bütünlüÄünün
> ve gizliliÄinin korunamamasından, virüs =
içermesinden ve bilgisayar sisteminize
> verebileceÄi herhangi bir zarardan sorumlu tutulamaz.
>=20
> This message and attachments are confidential and intended for the
> individual(s) stated in this message. If you received this message in =
error,
> please immediately notify the sender and delete it from your system. =
Our
> company has no legal responsibility for the contents of the message =
and its
> attachments. Our company shall have no liability for any changes or =
late
> receiving, loss of integrity and confidentiality, viruses and any =
damages
> caused in anyway to your computer system.
--=======AVGMAIL-5C492469=======
Content-Type: multipart/alternative;
boundary="=======AVGMAIL-09B732DD======="
--=======AVGMAIL-09B732DD=======
Content-Type: text/plain; x-avg=cert; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Description: "AVG certification"
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.34/2462 - Release Date: 10/27/09 0=
7:38:00
--=======AVGMAIL-09B732DD=======--
--=======AVGMAIL-5C492469=======
Content-Type: text/plain; charset=us-ascii
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--=======AVGMAIL-5C492469=======--
Re: What is the best practice for adding persistence to an
am 27.10.2009 16:30:11 von Paul M Foster
On Tue, Oct 27, 2009 at 05:27:07PM +1100, Eric Bauman wrote:
> I'm in the process of implementing an ultra-light MVC framework in PHP.
> It seems to be a common opinion that the loading of data from a
> database, file etc. should be independent of the Model, and I agree.
> What I'm unsure of is the best way to link this "data layer" into MVC.
I disagree. There should be database class(es) which know how to deal
with the datastore(s). This may be as simple as a thin layer over the
PDO classes. The model talks to and uses the database class, and is the
only component which deals with the database class. The model serves up
whatever data the controller needs to feed to the view.
All are welcome to disagree.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: What is the best practice for adding persistence to an MVC
am 27.10.2009 17:11:32 von David Otton
2009/10/27 Paul M Foster :
> On Tue, Oct 27, 2009 at 05:27:07PM +1100, Eric Bauman wrote:
>> I'm in the process of implementing an ultra-light MVC framework in PHP.
>> It seems to be a common opinion that the loading of data from a
>> database, file etc. should be independent of the Model, and I agree.
>> What I'm unsure of is the best way to link this "data layer" into MVC.
> I disagree. There should be database class(es) which know how to deal
Paul, you already did this in one of Eric's threads a couple of weeks
back, and the best you could come up with when pressed was "Probably
not a great example, but...". Is it really necessary to rehash this?
Eric, I recommend reading up on how to develop testable code
(especially Mock Objects) - it's great discipline because it requires
everything to be decoupled.
The short version is that it's often useful in unit testing to "fake"
the classes that your target relies on, so that you're testing it in
isolation. For example you could provide the class under test with a
fake DB class that returns static results.
It's much easier to do this when you pass objects /to/ your class:
class MyClass {
function MyClass($db) {
}
}
than when your class inherits from the object:
class MyClass extends Db {
}
or when the class instantiates the object:
class MyClass {
function MyClass() {
$this->db = new DB_CLASS;
}
}
If you go with the first approach, you're writing code that you and
anyone who comes after you can write useful tests for. The others, and
you're denying maintenance programmers a useful tool.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: What is the best practice for adding persistence to an
am 27.10.2009 17:39:12 von Paul M Foster
On Tue, Oct 27, 2009 at 04:11:32PM +0000, David Otton wrote:
> 2009/10/27 Paul M Foster :
>
> > On Tue, Oct 27, 2009 at 05:27:07PM +1100, Eric Bauman wrote:
>
> >> I'm in the process of implementing an ultra-light MVC framework in PHP.
> >> It seems to be a common opinion that the loading of data from a
> >> database, file etc. should be independent of the Model, and I agree.
> >> What I'm unsure of is the best way to link this "data layer" into MVC.
>
> > I disagree. There should be database class(es) which know how to deal
>
> Paul, you already did this in one of Eric's threads a couple of weeks
> back, and the best you could come up with when pressed was "Probably
> not a great example, but...". Is it really necessary to rehash this?
I don't track threads closely enough to know if it's the same OP on this
thread. Apologies if I'm repeating myself.
I don't recall anyone disputing my example, nor any effective rebuttal
at all. And by the time I finished writing that email, I thought it was
a better example than I originally believed.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: What is the best practice for adding persistence to an MVC
am 27.10.2009 17:39:32 von David Otton
2009/10/27 David Otton :
> If you go with the first approach, you're writing code that you and
> anyone who comes after you can write useful tests for. The others, and
> you're denying maintenance programmers a useful tool.
I should have lead with this: the wikipedia article on Dependency injection
http://en.wikipedia.org/wiki/Dependency_injection
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php