Let’s start with basics. The opposite of lazy loading is eager loading, which means “Load anything that can be needed. Ever.” In that approach model layer in Cake could look like that (it’s very simplified, the only relationship is belongsTo):

Eager Loading

class Model {
	function find(){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."`";

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
		if(isset($this->belongsTo) && is_array($this->belongsTo)){
			foreach($this->belongsTo as $related){
					$this->{$related} = new $related();
			}
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group");
}

class Group extends Model{
}

$user =  new User();

$user->find();
echo "
";
$user->Group->find();

One could see that Group object was initialized long before it is used:

creating User
creating Group
calling User::find()

string 'Select * from `users` as `User`' (length=31)

calling Group::find()

string 'Select * from `groups` as `Group`' (length=33)

Even more – it’s being initialized even if we don’t call any method in this object (comment $user->Group->find(); to see that).

Lazy Loading

class Model {
	function find(){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."`";

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
	}

	function __get($property){
		if(!isset($this->{$property})) {
			$this->{$property} = new $property();
		}
		if(in_array($property, $this->belongsTo)){
			return $this->{$property};
		}else{
			$r = new ReflectionClass($this);
			throw new Exception(
				"$property not related with {$r->getName()}"
			);
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group");
}

class Group extends Model{
}

$user =  new User();

$user->find();
echo "
";
$user->Group->find();

When using Lazy Loading pattern, Group object isn’t created untill we need it. Magic method __get() is used to make that possible. __get() is called whenever we try to access an attribute in object that doesn’t exists.

But there’s question of searching in model, so it returns appropriate data, ie. var_dump($user->find());

array
  0 =>
    array
      'User' =>
        array
          'id' => int 1
          'name' => string 'Frank' (length=6)
      'Group' =>
        array
          'id' => int 1
          'name' => string 'Admin' (length=5)
  1 =>
    array
      'User' =>
        array
          'id' => int 2
          'name' => string 'John' (length=5)
      'Group' =>
        array
          'id' => int 10
          'name' => string 'User' (length=4)

We know that belongsTo means that User should have field qroup_id, so the query could look like this:

Select User.id, User.name, Group.id, Group.name from users as User
Inner Join groups as Group on (User.group_id = Group.id)

(Now CakePHP, since 1.2 AFAIR, has Containable behavior, but it depends on loaded models).

Lets keep cake’s convention and assume, that we’ll pass informations about related elements through $contain variable.

function find($contain=null)

Now I want to say: object $user, please return me all users from database and groups they’re in:

$user =  new User();

$user->find(
	array(
		"belongsTo" => array($user->Group)
	)
);

Lets update find() method:

	function find($contain=null){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."` \n";

		if(!empty($contain) && is_array($contain["belongsTo"])){
			foreach($contain["belongsTo"] as $belongsToModel){
				$query .= $belongsToModel->getBelongsToJoin($this);
			}
		}

		var_dump($query);

		//return query result
	}

which now assumes that model has method, which can create the join part of query:

	function getBelongsToJoin($obj){
		$owner_reflection = new ReflectionObject($this);
		$obj_reflection = new ReflectionObject($obj);
		return "INNER JOIN `".strtolower($owner_reflection->getName())."s`
					as `".$owner_reflection->getName()."`
						ON (`".$owner_reflection->getName()."`.`id` = `".$obj_reflection->getName()."`.`".strtolower($owner_reflection->getName())."_id`)
					";
	}

it is ugly because we keep using reflections on and on. To make that prettier we could implements getName() method in Model class.

Anyway. Even in case of find which considers relations, we can use Lazy Loading pattern.

As a bonus, code sample with more related models and example of use (and small refactorin – when I write about Lazy Loading it looked silly when I was loading ReflectionClasss fifteen times ;)):

class ModelException extends Exception{}

class Model {

	protected $reflection = null;

	function getName(){
		if(is_null($this->reflection)){
			$this->reflection= new ReflectionClass($this);
		}
		return $this->reflection->getName();
	}

	function getTableName(){
		return strtolower( $this->getName() . "s" );
	}

	function getFKName(){
		return strtolower( $this->getName() . "_id");
	}

	function getBelongsToJoin($obj){
		$owner_reflection = new ReflectionObject($this);
		$obj_reflection = new ReflectionObject($obj);
		return "INNER JOIN `".$this->getTableName()."`
					as `".$this->getName()."`
						ON (`".$this->getName()."`.`id` = `".$obj->getName()."`.`".$this->getFKName()."`)
					";
	}

	function find($contain=null){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "\nSelect * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."` \n";

		if(!empty($contain) && is_array($contain["belongsTo"])){
			foreach($contain["belongsTo"] as $belongsToModel){
				$query .= $belongsToModel->getBelongsToJoin($this);
			}
		}

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
	}

	function __get($property){
		if(!isset($this->{$property})) {
			$this->{$property} = new $property();
		}
		if(in_array($property, $this->belongsTo)){
			return $this->{$property};
		}else{
			$r = new ReflectionClass($this);
			throw new ModelException(
				"$property not related with {$r->getName()}"
			);
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group", "Unit", "Company");
}

class Group extends Model{
}

class Unit extends Model{}
class Company extends Model{}

$user =  new User();

$user->find(
	array(
		"belongsTo" => array($user->Unit, $user->Company)
	)
);

What You think about that?

W tym wpisie skupię się na warstwie modelu.
Jest ona czasem nazywana warstwą biznesową aplikacji- i nie jest to przypadek. Dzieje się tak dlatego, że w niej zawarte są (albo powinny być) reguły biznesowe, które dany system realizuje. Przejdę jak najszybciej do przykładu, który to obrazuje.

Wyobraź sobie system zarządzania firmą wypożyczającą samochody. Cake wypiekł Ci CRUD dla modelu Cars i Costs (koszty generowane przez te samochody). Teraz klient informuje Cię o pewnej zasadzie, która brzmi:
“Każdy koszt można powiązać z dowolną ilością samochodów. Koszt może nie być powiązany z żadnym samochodem (koszt ogólny). Dane powiązanie koszt-samochód jest opatrzone konkretną kwotą (kwota powiązania). Jeśli koszt jest powiązany z jednym lub więcej samochodami, to suma kwoty ich powiązań musi się równać wartości kosztu. Czyli koszt musi być całkowicie rozdzielony na samochody, lub wcale.
Na przykładzie: mogę dodać koszt ‘naprawa po wypadku’, który powiążę z jednym samochodem na pełną kwotę. Mogę dodać koszt ‘ubezpieczenie za rok 2008′, które rozdzielę po równo między wszystkimi samochodami i mogę dodać ‘spinacze do biura’, którego nie powiąże z żadnym samochodem”.
To co właśnie usłyszałeś to reguła biznesowa, którą Twoja aplikacja musi obsłużyć.

Od razu oczywiście zabierasz się ochoczo za zdefiniowanie relacji wiele do wielu (HABTM) w modelach Cost i Car. Jeśli uważasz, że to wszystko i modele już będą jak zwykle służyć do wykonywania selectów na bazie- to sygnał, że możesz jeszcze nie rozumieć idei MVC, więc czytaj dalej.

Zabierasz się za implementowanie funkcjonalności. Bez większego zagłębiania się w szczegóły zbudujesz widok, w którym wybierzesz dla danego kosztu ileś samochodów z listy, wypełnisz ich kwoty i po kliknięciu zapisz poleci wszystko do kontrolera, a w nim będziesz miał 4 (o cztery za dużo) foreachów, którymi będziesz sprawdzał, czy suma się zgadza, a jeśli tak – pozwolisz na zapisz, bla, bla, bla. Jesteś zadowolony.

Jednak za miesiąc przychodzi klient i mówi: “fajne jest to przypisywanie kosztów do samochodów, ale ja chciałbym, żeby móc do kosztu przypisać samochody tylko na część kwoty”.
Jako porządny podwykonawca zgadzasz się, dajesz nura w kontroler i rozdmuchujesz go o pięć nowych ifów i trzy foreache, żeby obsłużyć wszystkie niuanse, które właśnie się pojawiły.

Ale licho… ekhm, klient nie śpi: “Skoro można przypisywać samochody do kosztów nie w całości – to chciałbym móc w widoku samochodu możliwość wybrania kosztów i je do niego przypisać”.
I co teraz robisz?

Jeśli zabierasz się za przeniesienie mechanizmów z kontrolera Costs do modelu Cost – może nie pójdziesz jeszcze do piekła. Jeśli zapaliła Ci się czerwona lampka, ale nie wiesz o co chodzi – czytaj dalej. Jeśli zaczynasz kopiować wspomniane mechanizmy do kontrolera Cars – jesteś w ciemnej du… hmm piwnicy. Dlaczego?

To, że łamiesz zasadę MVC to już powinieneś czuć przez skórę. Możesz jeszcze nie wiedzieć czym to grozi. To, że łamiesz zasady projektowania obiektowego – mogłeś nie zauważyć. Ale, że masz w dwóch różnych miejscach (CostsController i CarsController) mechanizm robiący to samo i Ci to nie przeszkadza – za to właśnie trafisz do piekła.

Powtórzenie, które przed chwilą opisałem ma dwie poważne konsekwencje:
1. Mechanizmy dbające o spójność bazy danych masz rozproszone w wielu klasach. Dlatego zmiana reguły biznesowej pociąga za sobą konieczność zmiany wielu dublujących się wierszy kodu. Łatwo wtedy o pomyłkę.

2. Model nie dba samodzielnie o spójność danych. Pisząc w ten sposób aplikację zakładasz, że każdy programista w każdym momencie rozwoju aplikacji (czyli nawet za dwa lata) będzie dokładnie pamiętał tą (i wszystkie inne) reguły biznesowe. Dodając kolejny element, znów będzie musiał samodzielnie zadbać o każdy aspekt spójności danych. Łatwo wtedy o pomyłkę.

Dlatego o spójność danych musi dbać warstwa modelu. Bo ona dba o sama siebie. Jeśli odpowiednio zaprojektujesz model Cost, przy pomocy callback’ów beforeValidate, before i afterSave zawrzesz w modelu zapewnienie spójności, wszystko co pozostanie w przyszłości do zrobienia to przygotowanie odpowiedniej tablicy w kontrolerze i wywołanie $this->Cost->save(…).

Dlatego czwartą zasadę formułuję następująco:
mechanizmy dbające o spójność bazy danych umieszczaj w warstwie modelu

ps. Witam wszystkich po przydługiej przerwie wakacyjno-inietylko ;)