I am learning OO SOLID principles and design patterns and I want to do some practice on it. So I get the one problem from my ongoing project and try to design it. Please check whether it is implemented correctly or it's over-engineered or I implement it poorly. Your response is most important.
Problem
I have to manage sms and email campaigns in one system. I meant to say storing it in database and retrieving it etc.
So I think there will be something specific to the Campaign like created date status etc. Thus I have made the class named campaignmodel which is responsible for some common functions related to campaign
Class CampaignModel
{
public function save($data)
{
// add campaign specific data
// save the campaign.
}
public function get()
{
// select the row from database and return it.
}
}
then I make smscampaign and email campaign
class SMSCampaignModel extends CampaignModel
{
public function save($data)
{
// add sms specific data and
parent::save($data);
}
public function gets()
{
//fire the query to get the sms campaigns and returns it.
}
}
class EmailCampaignModel extends CampaignModel
{
public function save($data)
{
// add email specific data
parent::save($data);
}
public function gets()
{
//fire the query to get the email campaigns and returns it.
}
}
Now every campaign will have recipients and we have to store each recipient's status like he opens mail or mail/sms sent or failed etc. I think we will send the campaigns with many emails or numbers so I decided to create different database table for storing such details such as sms_campaign_log, email_campaign_log etc. I have created the interface for it
interface CampaignLogs
{
function insert_log();
function get_details();
}
class SmsCampaignLogs implements CampaignLogs
{
public function insert_log($data)
{
// get the number and status save it into the sms logs table.
}
public function get_details($campagin_id)
{
// get the logs from campagin table and return it.
}
}
class EmailCampaignLogs implements CampaignLogs
{
public function insert_log($data)
{
// get the number and status save it into the email logs table.
}
public function get_details($campagin_id)
{
// get the logs from campagin table and return it.
}
}
and lastly I think now I should use strategy pattern to implement it(I don't know whether it is correct or not).
class Campaign
{
private $log;
private $campaign_type;
public function __construct($campaign, $logger)
{
$this->campaign_type = $campaign;
$this->log = $logger;
}
public function save($data)
{
$this->campagin_type->save();
}
public function gets()
{
$this->campaign_type->gets();
}
public function log($data)
{
$this->log->insert_log($data);
}
public function get_campaign_details($campaign_id)
{
$this->log->get_details($campaign_id);
}
}
now Implementation code.
$campaign = new SmCampaignModel();
$logger = new SmsCampaignLogs();
$c = new Campaign($campagin,$logger);
$c->save($data);
$c->get($campaign_id);
$c->get_campaing_details();
Then I think if strategy pattern needed.
Simply, I can implement:
$campaign = new SmCampaignModel();
$logger = new SmsCampaignLogs();
$campaign->save($data);
$campaign->get($campaign_id);
$logger->get_campaing_details($campaign_id);
So I am now totally confused. I want your opinion on whether I applied SOLID principles correctly in my design (and strategy pattern is needed/used properly) or not.
In this case your Campaign class is only a Facade. No Strategy is in use.
You are actually using the Facades pattern and not the Strategy. Your Campaign class doesn't have a behavior of it own. It merely delegates its behavior to subsystem components. It is not a bad thing, but it makes your code somehow harder to maintain. It is fine in terms of information hiding.
There is not right or wrong in the aspect of OOD. Design patterns are not must to be included if no reason is presented. You should ask yourself: "What is my main problem, and does this solve it?". "Will there be a reason to the code to be changed often?".
Because we are all sometimes tempted to overuse design patterns, I would like to show you how making a simple OO relationship will do just fine, and will even be easier to read and maintain.
abstract class Campaign {
protected $ages;
protected $countries;
protected $dailyBudget;
protected $recipientsStatus = array(); // associative array or a composition of Recipients object
public function startCampaign()
{
// check there is not another run
$this->executeCampaign();
$this->collectRecipientsStatus();
$this->generateStatistics();
}
abstract protected function executeCampaign();
abstract protected function collectRecipientsStatus();
abstract protected function generateStatistics();
}
class EmailCampaign extends Campaign {
protected $addresses;
protected function executeCampaign()
{
$this->filterEmailsByCampaignData();
$this->sendEmails();
}
protected function filterEmailsByCampaignData()
{
// populate $this->addresses based on ages, countries etc.
}
protected function sendEmails()
{
// send email to addresses
}
protected function collectRecipientsStatus()
{
// collect status and fill parent $recipientsStatus
}
protected function generateStatistics()
{
// generate statistics
}
}
Campaign now is a class with data and behavior. We don't have to decouple it into components like Model and Logs. This will work just fine. However, if you ever find yourself with a bit more complicated Recipients array (too many key values or dimensional array code smells), then you might decouple it into another set of classes. But this should happen with evolution of the code. We simply cannot foresee everything in advance.
By the way, the only pattern I used is the lightweight Template Method, and inheritance feature of OOP.
Related
I'm very sorry for the cryptic title, but I honestly have no idea how to describe it in a short, title-style fashion.
First short version. Simple email confirmation mechanism. One method is sending email with confirmation link. After clicking the link, another controller invokes second method, which verifies token from the URL. Between both actions ConfirmationObject is being stored, with the token and possible other data. After successful confirmation "successHandler" is being used.
Simplified code:
interface SuccessHandlerInterface {
public function success(ConfirmationObjectInterface $object);
}
class EmailTester {
public function try(ConfirmationObjectInterface $object) {
// some code
}
public function confirm($token) {
$confirmationObject = $this->repository->findByToken($token);
$type = $confirmationObject->getType();
$successHandler = $this->handlersRegistry->getSuccessHandler($type);
$successHandler->success($confirmationObject);
}
}
Now we are going to use it this way:
// Firstly let's implement our own success handler.
class UserRegistrationSuccessHandler implements SuccessHandlerInterface {
public function success(ConfirmationObjectInterface $object) {
// Do some stuff on success.
}
}
// Then let's register this success handler to be available in our `handlersRegistry` object.
$handlersRegistry->addType('user_registration', new UserRegistrationSuccessHandler());
// Now we will extend ConfirmationObjectInterface
interface RegistrationConfirmationObjectInterface extends ConfirmationObjectInterface {
public function getSomeDataGivenOnRegistration();
}
// And at the end, let's try our email
$confirmationObject = new RegistrationConfirmationObject(); // Which implements above interface.
// $confirmationObject->getType() === 'user_registration'
$emailTester->try($confirmationObject);
// Now confirmation link with token is being sent to the given email. If user will click it, below method will be invoked.
$emailTester->confirm($token);
The problem now is that I would rather like to have RegistrationConfirmationObjectInterface in the success handler available, rather than ConfirmationObjectInterface.
I know I can do:
// Firstly let's implement our own success handler.
class SuccessHandler implements SuccessHandlerInterface {
public function success(ConfirmationObjectInterface $object) {
if ($object instanceof RegistrationConfirmationObjectInterface) {
// Do stuff
}
}
}
But it feels bad. This check is pointless as $object will always be an instance of RegistrationConfirmationObjectInterface. How is this design flawed, and how it could be improved?
It is unclear to me why the Confirmation Objects should implement two interfaces. From what I see here, RegistrationConfirmationObjectInterface only has one method that returns some data structure, and ConfirmationObjectInterface has no methods at all. Is strict type safety really necessary here, especially if you're certain that your custom SuccessHandler will receive RegistrationConfirmationObjectInterface at all times?
If ConfirmationObjectInterface implementations contain no logic and are just data structures, replace them with associative arrays. Otherwise, I would suggest something like this:
interface ConfirmationObjectInterface
{
/**
* #return array
*/
public function getData();
}
class RegistrationConfirmationObject implements ConfirmationObjectInterface
{
public function getData()
{
return ['data specific to registration here'];
}
}
class SomethingElseConfirmationObject implements ConfirmationObjectInterface
{
public function getData()
{
return ['data specific to something else'];
}
}
Since custom handlers are specific to concrete types, they will know what data to expect from getData() anyway.
I have read a lot in the past few days about domain objects, data mappers, and a bunch of other stuff I had no idea about.
I have decided to try and implement this in a bit of code I am writing (partly for learning purposes, and partly because I want to create a REALLY simplified framework to build a few projects quickly...with code that I can easily understand and modify).
After reading this and this, I was planning on creating a SINGLE data mapper, with a connection to the DB inside of it, and then use a factory to pass the data mapper into every domain object (well, the ones that would need it). I include some sample code below
class data_mapper {
private $dbh;
function __construct()
{
$this->dbh = new PDO(DB_STRING, DB_USER, DB_PASS);
}
public function createUser($data) ...
public function updateUser($user_id, $data) ...
public function createCategory($data) ...
}
class user {
private $data_mapper;
public $user_id;
public $data;
function __construct($dm)
{
$this->data_mapper = $dm;
}
function someFunction() {
/* some code */
$this->data_mapper->updateUser($user_id, $data);
/* some more code */
}
}
class factory {
private $data_mapper = null;
function __construct($dm)
{
$this->data_mapper = $dm;
}
public function create($name)
{
return new $name($this->data_mapper);
}
}
/* USAGE */
$dm = new data_mapper();
$factory = new factory($dm);
$user = $factory->create('user');
I am left with two questions:
A lot of recent examples I've looked at create a different data_mapper for each model. Should I be doing this? And if I do, wouldn't that make the factory much more complex (i.e. I would need to create single PDO object and pass that into each data mapper, and then pass the right data mapper into each model)?
If my above code exposes some flaw in the understanding of models, data mappers or anything else, please enlighten me (not really a question, i know)...
As far as I can tell, "data mapper" pattern implemented in modern frameworks in the form of prototype Model class, from which all application models are inherited.
In this prototype model you can implement CRUD methods and thus your models will possess it.
Speaking of passing pdo around, local scholars will tell you that you should pass PDO object as constructor parameter. But if you'll take a look at any modern framework - they are using some sort of singleton that contains a PDO instance
So, you want a REALLY simplified PHP framework. Data mappers sound like over-engineering.
Over the years i made a few KISS frameworks in PHP, this is what i did:
Use templates (aka view) such as Smarty. Great for outsourcing your webdesign.
Make a folder named pages (aka controller). Pages are called by index.php only.
Make a folder named models. Only models talk with your DB.
Make a index.php (aka router). Has a ?page=dog parameter.
Strict MCV (aka MVC) terminology is not the holy grail, the above is a nice implementation for a simple website/app/CMS.
The parts
/pages/page_dog.inc.php
A page loads the model(s) he needs, manipulates and shows it:
<?php if(!defined('YOURFRAMEWORK')){die('External access denied');}
// Page init
require './models/model_dog.inc.php';
$id = $_GET['id']; // todo fix injection attacks
$ModelDog = new ModelDog($DB);
// Page main
$ModelDog->Load($id);
echo $ModelDog->item['breed'];
For listings (a page where user selected the $id) you may not want seperate models representing each result. Make a lister class instead, much like the model but returning multiple items in one array. Its tempting to DRY and make the ListerDog class use the ModelDog but there is no readability gain just performance pain.
/index.php (aka router) calls a page (via require_once()) after auth and init ($DB):
<?php
define('YOURFRAMEWORK', 1); // disable "External access denied" error.
require_once('config.inc.php'); // todo have this hold the $config[] array.
$DB = #new mysqli( // or your derative, so you can log each query() call.
$config['db']['host'],
$config['db']['user'],
$config['db']['pasw'],
$config['db']['database']
);
if ($DB->connect_error) { die('db error: ' . mysqli_connect_errno()); }
// Load page requested by user. For now, its dog hardcoded.
require_once('./pages/page_dog.inc.php');
$DB->close;
/models/model_dog.inc.php (aka model) talks to the DB for you, processes and sanitizes data. I also use this put form processing functions.
<?php if(!defined('YOURFRAMEWORK')){die('External access denied');}
class ModelDog extends BaseModel {
private $tablename = 'dogs';
/**
* Load last (or specific) item.
* #param integer $id
* #return boolean Returns false when failed.
*/
public function Load($id=null) {
$query = "SELECT * FROM `".$this->tablename."` WHERE `id`='".$this->DB->Sanitize($id)."';";
// TODO .. $this->item =
}
public function ItemDefaults() {
return array(
'id' => 0,
'breed' => 'unknown',
'height' => 0
);
}
// TODO ..
}
/models/basemodel.inc.php extend every model class from something common like:
abstract class BaseModel
{
protected $item = array(); // Here is all the data!
protected $DB = null;
public function __construct($aQDB) {
parent::__construct();
$this->DB = $aDB;
$this->Reset();
}
public function Reset() {
$this->item = ItemDefaults();
}
public function Item() { return $item; }
// As seen in dog
abstract public function Load($id);
abstract public function ItemDefaults();
// But descendants (models) must also implement:
abstract public function Save($id = NULL);
abstract public function Delete($id);
// You may want to add Validate() and other internal things here.
}
All of the above is a bare-minimum version of what i build myself when i need another tiny framework. You gain more in proper subclassing than making more classes doing more things. A website is a simple thing in essence, until one overcomplicates it..
The gist / TLDR;
If you really want a REALLY simplified PHP framework, dont read to much. Just write code and you'll discover what it needs to make you work better.
I'm working with a domain model, in which I have a Reservation class:
class Reservation
{
public function changeStatus($status) { ... }
}
Because the changeStatus() method should only be called in a context where all appropriate notifications are sent (emails, ...) I would like to restrict the call to this method to a ReservationService:
class ReservationService
{
public function confirmReservation(Reservation $reservation)
{
$reservation->changeStatus(Reservation::STATUS_CONFIRMED);
// commit changes to the db, send notifications, etc.
}
}
Because I'm working with PHP, there is no such concept as package visibility or friend classes, so my changeStatus() method is just public and therefore callable from anywhere in the application.
The only solution I found to this problem, is to use some kind of double dispatch:
class Reservation
{
public function changeStatus(ReservationService $service)
{
$status = $service->getReservationStatus($this);
$this->setStatus($status);
}
protected function setStatus($status) { ... }
}
The potential drawbacks are:
That complicates the design a bit
That makes the entity aware of the Service, no sure whether that's actually a drawback or not
Do you guys have any comment on the above solution, or a better design to suggest to restrict access to this changeStatus() method?
Use an interface which enforces the context you need:
interface INotifiable {
public function updated( $reservation );
}
class Reservation {
public function changeStatus( $status, INotifiable $notifiable ){
$this->setStatus( $status );
$notifiable->updated( $this );
}
}
class EmailNotifier implements INotifiable {
public function updated( $reservation ){
$this->sendUpdateEmail( $reservation ); //or whatever
}
}
The reservation then doesn't need to know anything about the service. An alternative would be to define events on Reservation, but that's added complexity you probably don't need.
You can send messages from one domain entity to another. Only objects that are capable of producing certain messages will call the method in question. A code snippet is below. This solution is for projects where dependency injection is a sort of religion like here PHP+DDD.
The Reservation Service gets a message factory. The factory is injected through the constructor method. Objects that don't have this factory cannot issue this sort of messages. (Of course you must restrict object instantiation to factories.)
class Domain_ReservationService
{
private $changeStatusRequestFactory;
public function __construct(
Message_Factory_ChangeStatusRequest $changeStatusRequestFactory
) {
$this->changeStatusRequestFactory = $changeStatusRequestFactory;
}
public function confirmReservation(Domain_Reservation $reservation) {
$changeStatusRequest = $changeStatusRequestFactory->make(
Reservation::STATUS_CONFIRMED
);
$reservation->changeStatus($changeStatusRequest);
// commit changes to the db, send notifications, etc.
}
}
The Reservation object checks the contents of the message an decides what to do.
class Domain_Reservation
{
public function changeStatus(
Message_Item_ChangeStatusRequest $changeStatusRequest
) {
$satus = $changeStatusRequest->getStatus();
...
}
}
Message object is a DDD value object. (Sometimes it acts like a strategy.)
class Message_Item_ChangeStatusRequest
{
private $status;
public function __construct( $status ) {
$this->$status = $status;
}
public function getStatus() {
return $this->$status;
}
}
This factory produces messages.
class Message_Factory_ChangeStatusRequest
{
public function make($status) {
return new Message_Item_ChangeStatusRequest ($status);
}
}
All domain objects are produced by this layer factory.
class Domain_Factory
{
public function makeReservationService() {
return new Domain_ReservationService(
new Message_Factory_ChangeStatusRequest()
);
}
public function makeReservation() {
return new Domain_Reservation();
}
}
The classes above can be used in your application as follows.
$factory = new Domain_Factory();
$reservationService = $factory->makeReservationService();
$reservation = $factory->makeReservation();
$reservationService->confirmReservation($reservation);
But I don't see why you don't want to use $reservation->beConfirmed() instead of passing status constants.
It actually sounds like this is missing a very important concept, namely a ProcessManager. A ProcessManager represents a distributed business transaction spanning multiple contexts. In reality it is a simple Finite State Machine.
An example workflow:
A PlaceReservationCommand is sent to the ReservationContext, which handles it and publishes a ReservationWasPlacedEvent that the ReservationProcessManager is subscribed to.
The ReservationProcessManager receives the ReservationWasPlacedEvent and validates that it can transition to the next step. I then sends a NotfiyCustomerAboutReservationCommand to the NotificationContext. It now listens to ReservationNotificationFailedEvent and ReservationNotificationSucceededEvent.
Now the ReservationProcessManager sends the ConfirmReservationCommand to the ReservationContext only when it received the ReservationNotificationSucceededEvent.
The trick here is that there is no status field in Reservation. The ProcessManager is responsible of tracking the state of this business transaction. Most likely there is a ReservationProcess Aggregate that contains the statuses like ReservationProcess::INITIATED,
ReservationProcess::CUSTOMER_NOTIFICATION_REQUESTED, ReservationProcess::CUSTOMER_NOTIFIED, ReservationProcess::CONFIRMATION_REQUESTED and ReservationProcess::CONFIRMED. The last state indicates a finite state that marks the process as done.
One of the things that the Symfony2 and FLOW3 frameworks have adopted is tagging their stable public API with an #api annotation comment.
While this is not exactly what you're looking for, it comes close. It documents the parts of your API that users can rely on. Plus your entity does not have to know about the service, avoiding the evil circular dependency.
Example:
class Request
{
/**
* Gets the Session.
*
* #return Session|null The session
*
* #api
*/
public function getSession()
{
return $this->session;
}
}
I'm wondering if anyone could give me a suggestion for to best handle this situation:
I have several systems from which to pull data to display on a single PHP-driven website. The type of information will be the same across systems (contacts, addresses, etc) but the way I pull data (MS-SQL, XML, REST) will not.
I want to create a class, or set of classes, for each of the connection types and use simple methods such as getContact(), getAddress(), etc. I am wondering how best to structure this.
The most obvious way that comes to mind means creating classes for each connection type, like:
class.sys_mysql.php. class.sys_xml.php, etc
But then won't I be duplicating the methods in each class? Maybe that's OK, but I'm curious if there's a better way, as far as future maintenance goes.
Maybe I should simply isolate the queries/data extraction methods, into separate class files? Classes within classes? Extended classes? I'm less familiar with these.
Any advice would be greatly appreciated.
DC
--------- more info ----------
Hi all. I really appreciate all the great advice. Not to belabor this thread but I'm still a bit confused on how I should break things down. I will try and be a bit more specific:
Basically, I have 3 (more in the future) offices, from which one PHP website pulls information. Each office uses a different CRM, and a different system for interfacing with that CRM. One uses MSSQL, another XML requests, etc.
Each office wants to display information similarly on the website, but there are minor differences. There may be more differences in the future. However, there are by far more similarities, and so I want to capitalize on higher level functions like getContacts($id) which are shared between them.
I am trying to write these classes so I can:
1) use higher level methods to pull data easily
2) account for different ways of pulling data (xml,sql,etc)
3) account for differences between how data is displayed on the website (office 1, office 2, office 3)
4) manage the connection credentials for each office and allow for expandability_
5) I should also mention that I will be creating separate classes for reporting, sending out automated e-mails, calculating finances...separate modules that will need to use existing classes to pull data.
I realize that some of the examples here see to cover 1 and 2, but I am confused as to how to get 3, 4 and 5 working with 1 and 2.
I really appreciate the help.
DC
This is what Interfaces are for.
You define the methods required to interact with the data in an Interface, and then you create classes that implement that Interface
If some of the systems have similar access models (i.e. perhaps two different DB Servers, but both are accessed using PDO) you could abstract it further and put the "low level" functionality into service-specific classes (which implement an Interface) and then a higher-level class which defines the actual methods you use.
Another option is that you could put the "common" methods (those that are identical or can be made idetntical with service-type checks) into a base class, which all others extend.
Example for option one:
interface DataModel {
public function findContacts($search);
public function getContact($id);
public function findAddresses($search);
public function getAddress($id);
}
class XMLDataModel implements DataModel {
public function findContacts($search) {
...
}
public function getContact($id) {
...
}
public function findAddresses($search) {
...
}
public function getAddress($id) {
...
}
}
class RESTDataModel implements DataModel {
public function findContacts($search) {
...
}
public function getContact($id) {
...
}
public function findAddresses($search) {
...
}
public function getAddress($id) {
...
}
}
As you can see, you simply define an Interface, which specifies which methods a class must implement.
If you had two very similar classes, perhaps one for MySQL and one for PostreSQL, and you can't/don't want to combine them into a single PDO class, you could do the following:
class PDODataModel implements DataModel {
private $model;
public function __construct ($serverType) {
if ($serverType === 'mysql') {
$this->model = new MySQLPDODataModel();
}
elseif ($serverType === 'postgresql') {
$this->model = new PostgresQLPDODataModel();
}
}
public function findContacts($search) {
// common logic about $search, perhaps checking it's a valid search?
$result = $this->model->searchForContacts($search);
// more common logic, maybe higher level filtering..
return $result;
}
public function getContact($id) {
...
}
public function findAddresses($search) {
...
}
public function getAddress($id) {
...
}
}
interface PDODataModelDriver {
public function searchForContacts($search);
}
class MySQLPDODataModel extends PDODataModel implements PDODataModelDriver {
public function searchForContacts($search) {
// MySQL-specific query to search for contacts
}
}
class PostgresSQLPDODataModel extends PDODataModel implements PDODataModelDriver {
public function searchForContacts($search) {
// PostgreSQL-specific query to search for contacts
}
}
The other option I mentioned was to work in the opposite direction:
abstract class PDODataModel implements DataModel {
protected $pdo;
protected $dsn;
public function __construct () {
$this->pdo = new PDO($this->dsn);
}
public function findContacts($search) {
// common logic about $search, perhaps checking it's a valid search?
$result = $this->searchForContacts($search);
// more common logic, maybe higher level filtering..
return $result;
}
public function getContact($id) {
...
}
public function findAddresses($search) {
...
}
public function getAddress($id) {
...
}
}
class MySQLPDODataModel extends PDODataModel {
protected $dsn = 'mysql:dbname=testdb;host=127.0.0.1';
protected function searchForContacts($search) {
// MySQL-specific query to search for contacts
}
}
class PostgresSQLPDODataModel extends PDODataModel {
protected $dsn = 'pgsql:host=localhost;port=5432;dbname=testdb';
protected function searchForContacts($search) {
// PostgreSQL-specific query to search for contacts
}
}
This is a classical example of a strategy design patter. Your first mind was absolutely fine, but if you're repeating yourself in each class you should consider creation of a abstract class that will handle the common code.
So it could look like this:
$myService = new MyService(new XMLReader('/path/to/file'));
echo $myService->getContanct('abc')->getName();
And skeleton of your classes:
class MyService {
private $reader;
public function __construct(ReaderInterface $reader) {
$this->reader = $reader;
}
// ...
public function getContacnt($id) {
$contact = $this->reader->getContact($id);
// do some extra stuff here
return $contact;
}
}
interface ReaderInterface {
public function getContanct($id);
public function getAddress($id);
}
abstract class AbstractReader implements ReaderInterface {
protected $loaded = false;
protected $data = array();
abstract protected function load();
public function getContanct($id) {
if ($this->loaded == false) {
$this->load();
$this->loaded = true;
}
return $this->data['contact'][$id];
}
}
class XMLReader extends AbstractReader {
public function __construct($filepath) {
...
}
protected function load() {
...
foreach (...) {
$this->data[...] = ...;
}
}
}
class MSSQLReader extends AbstractReader {
public function __construct(PDO $dbh) {
...
}
protected function load() {
...
while ($row = $stmt->fetchRow()) {
$this->data[...] = ...;
}
}
}
EDIT (2011-03-07) - According to your comment.
PHP supports variable variables (new $type()) but never use this! It's a horrible, and if overused make code really crappy.
This is a yet another example of a "classical issue". Use a factory pattern (depending on the complexion of the creation you might want to use more abstract variety of this pattern - abstract factory
When you need to dynamically determine class name (eg. from variable) use reflection API to instate an object.
You should create an object-storage mapping layer for each data source, which instantiates the objects into storage agnostic model objects. See http://martinfowler.com/eaaCatalog/dataMapper.html
If you have control over the structure of your data formats, I suggest you serialize your data in a consistent way (especially in XML) and provide drivers for each data format.
For instance, every driver will have 'findAll', 'getOne', 'count', etc. methods. The driver can be given a model to populate with the retrieved data.
abstract class DataDriver {
function __construct($model) {}
abstract public function findAll();
abstract public function getOne();
abstract public function count();
// ...
}
class XMLDriver extends DataDriver {
// implements all the methods
}
class SQLDriver extends DataDriver {
// implements all the methods
}
class Contact {
public var $firstName;
public var $lastName;
function getFullName() {
return trim($this->firstName . ' ' . $this->lastName);
}
}
$accessor = new SQLDriver('Contact');
$contacts = $accessor->findAll();
If your data will be serialized in an uncontrolled manner, the approach you suggest is the best. Just make sure to separate your models (e.g. Address book, Contact) from the method of retrieval (eg. get_address_book_xml, get_address_book_sql, etc.)
Of course there are many ways of separating your models from your data-mapping driver. The importance is you find the solution that works best for you given that you're using such different formats.
So, lets say I have a record:
$record = new Record();
and lets say I assign some data to that record:
$record->setName("SomeBobJoePerson");
How do I get that into the database. Do I.....
A) Have the module do it.
class Record{
public function __construct(DatabaseConnection $database)
{
$this->database = $database;
}
public function setName($name)
{
$this->database->query("query stuff here");
$this->name = $name;
}
}
B) Run through the modules at the end of the script
class Record{
private $changed = false;
public function __construct(array $data=array())
{
$this->data = $data;
}
public function setName($name)
{
$this->data['name'] = $name;
$this->changed = true;
}
public function isChanged()
{
return $this->changed;
}
public function toArray()
{
return $this->array;
}
}
class Updater
{
public function update(array $records)
{
foreach($records as $record)
{
if($record->isChanged())
{
$this->updateRecord($record->toArray());
}
}
}
public function updateRecord(){ // updates stuff
}
}
A question you could ask yourslef is whether you want to reinvent the wheel or not. ORM layers like Propel or Doctrine already implement object to (R)DBMS mapping, so you might look at their implementation details.
Propel will use your second approach, they even keep flags on a field level to create just one update statement (which will keep database interaction at a minimum). You'll learn a lot if you study their source (or better yet, stop wasting your time and use their implementation - you won't regret it :p).
It depends on how you plan to implement... Doing all the writes at a single point (at the end of a request) is nice because it allows you to optimize your operations by consolidating queries where possible. But to do that you have to create something similar to a UnitOfWork to keep track of whats a delete/update/insert which can open a whole other can of worms.
On the other hand if you do it directly when you call the persistence method on the entity then you dont have to worry about that quite as much.
Both approaches though mean you have to have some way to make sure you always have the current data in your object but the work required to implementation that varies in complexity with he approach you choose.
Example A updates the database whenever setName is called. This function looks like a simple write accessor but it performs expensive actions when called (connecting to the database, executing a query, etc). These unintended site-effects make Example B far more appealing.
As a further example: Later on you might need a Validator class that examines a Record and ensures that the Record is in a valid state. But in order to examine the Record you must define it first by setting a name - so the Record will be persisted before you can validate it's state. Defining object state is not the same as persisting object state.
A data model approach might work better instead of a record-based approach. For instance:
class Model {
protected $_props= array();
public $changed= false;
static public $models= array();
function __set($name, $value) {
$this->changed= true;
$this->_props[$name]= $value;
}
function __construct() {
Model::$models[]= $this;
}
public function save() {
// Execute database query for saving the current Model
}
static public function update() {
foreach (Model::$models as $model) {
if ($model->changed) {
$model->save();
}
}
}
}
A model-based solution really shines when it comes to creating different Model types. For instance:
class Person extends Model {
public function save() {
// Execute person-specific write operations
}
}
class Doctor extends Person {
public function save() {
// Execute all Person write operations
parent::save();
// Save the extra bits that belong to a doctor
}
}
$person1= new Person();
$person->firstname= 'Jon';
$person->lastname= 'Skeet';
$doctor1= new Doctor();
$doctor1->firstname= 'House';
$doctor1->lastname= 'MD';
// Save all modified models
Model::update();
Though I rarely find use for these kind of mass update mechanisms. Write conditions are usually more specific.