First of all I am sorry that I am not able to provide you much details and my question might sound to general.
I am working on a small project but the requirement of the project is bit wired. I have to make the data source switchable. So if I am using Database as a data source now in future it might be able to use a web service or files.
I don't have any clue on how to implement my models so that I can switch the data source without making major changes to the application.
Is there a design pattern or any design practices which I can use to deal with this situation?
I am planning on using Zend Framework.
Thanks for your help in advance.
Take a look at DAOs (Data Access Object). Originally it's existing in the j2ee world but is very simple, thin and usefull.
First you define an interface with whatever function you need:
<?php
interface DAOInterface {
public function insert($object);
public function remove($object);
public function create($object);
}
Then create a concrete implementation of it. This implementation is easily exchangeable with Dependecy Injection (DI). You can have several different ways of storing your data now. You'll always use the interface + DI.
One interface ->Multiple differen implementations / ways of stroing data. Typically one DAO = one database object / table.
Use an interface that declares methods like GetModel1 and GetModel2 etc. Make an implementation of that interface that gets it from the database. If you switch to service methods you can write a new implementation for that interface.
By doing this you won't have to rewrite any of the other code, because from the outside looking in, GetModel1 with the database implementation will work the same as GetModel1 in the services version, in that you make a call, some magic happens on the other side of the interface, and you get a Model1 in return.
If at some point you need to switch implementations during runtime (say, get from DB when offline, but get from service if available) you can create something similar to a design pattern called dependency injection.
It really depends on your application architecture for the specifics on this, but I will give you an example of what works generally.
You want to separate your database calls into separate files/classes from the rest of your code.
For example:
Person class:
getPerson -> calls PersonConnectionClass::queryForPerson($x);
In the most basic form, you simply swap out the PersonConnectionClass when you switch database engines or other data sources (i.e. xml, flat files, etc).
Just thinking about it a little bit, you can see how you can make this fancier by specifying your datasource in a config file. Then using programming logic to determine which datasource you use.
I am not familiar with the Zen framework, but the design patterns you are looking for are Data Access Object and Data Transfer Objects.
Data Access Objects are used for:
Without knowing too many details of your project, I would suggest implementing a data access interface and then implementing that interface with different data access objects, depending on the type of persistence.
This can be done using the Data Mapper pattern; it encapsulates the logic to fetch, update, insert and delete your domain objects from persistent storage.
First, you introduce the interface that will be used.
interface UserMapperInterface
{
public function get($id);
public function update(User $user);
public function insert(User $user);
public function remove(User $user);
}
Then, you create a database specific class that implements the interface:
class PDOUserMapper implements UserMapperInterface
{
private $dbh;
public function __construct(PDO $dbh)
{
$this->dbh = $dbh;
}
public function get($id)
{
// do queries using $this->dbh
}
}
Code that uses any of the mappers should type hint the interface rather than a concrete class, e.g.:
function fetchUser(UserMapperInterface $mapper, $id)
{
return $mapper->get($id);
}
Because your code only works with the interface you can easily swap out the concrete classes.