...

понедельник, 21 октября 2013 г.

[Из песочницы] Active Record против Data Mapper-а для сохранения данных

Эти 2 шаблона проектирования описаны в книге Мартина Фаулера «Шаблоны корпоративных приложений» и представляют собой способы работы с сохранением данных в объектно-ориентированном программировании.

Пример шаблона Active Record



class Foo
{
protected $db;
public $id;
public $bar;

public function __construct(PDO $db)
{
$this->db = $db;
}

public function do_something()
{
$this->bar .= uniqid();
}

public function save()
{
if ($this->id) {
$sql = "UPDATE foo SET bar = :bar WHERE id = :id";
$statement = $this->db->prepare($sql);
$statement->bindParam("bar", $this->bar);
$statement->bindParam("id", $this->id);
$statement->execute();
}
else {
$sql = "INSERT INTO foo (bar) VALUES (:bar)";
$statement = $this->db->prepare($sql);
$statement->bindParam("bar", $this->bar);
$statement->execute();
$this->id = $this->db->lastInsertId();
}
}
}

//Insert
$foo = new Foo($db);
$foo->bar = 'baz';
$foo->save();




В этом упрощенном примере, дескриптор базы данных вводится в конструкторе Foo (Использование инъекции зависимостей здесь позволяет тестировать объект без использования реальной базы данных), и Foo использует его, чтобы сохранять свои данные. Do_something — просто метод-заглушка, заменяющий бизнес логику.

Преимущества Active Record





  • Писать код с Active Record получается быстро и легко, в том случае, когда свойства объекта прямо соотносятся с колонками в базе данных.

  • Сохранение происходит в одном месте, что позволяет легко изучить, как это работает.




Недостатки Active Record





  • Модели Active Record нарушаю принципы SOLID. В частности, принцип единой ответственности (SRP — «S» в принципах SOLID). Согласно принципу, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. Вызывая его для сохранения данных, вы добавляете ему дополнительную зону ответственности, увеличивая сложность объекта, что усложняет его поддержку и тестирование.

  • Реализации сохранения данных тесно связана с бизнес-логикой, а это означает, что если вы позже захотите использовать другую абстракцию для сохранения данных (например для хранения данных в XML-файле, а не в базе данных), то вам придется делать рефакторинг кода.




Пример Data Mapper-а



class Foo
{
public $id;
public $bar;

public function do_something()
{
$this->bar .= uniqid();
}
}

class FooMapper
{
protected $db;

public function __construct(PDO $db)
{
$this->db = $db;
}
public function saveFoo(Foo &$foo)
{
if ($foo->id) {
$sql = "UPDATE foo SET bar = :bar WHERE id = :id";
$statement = $this->db->prepare($sql);
$statement->bindParam("bar", $foo->bar);
$statement->bindParam("id", $foo->id);
$statement->execute();
}
else {
$sql = "INSERT INTO foo (bar) VALUES (:bar)";
$statement = $this->db->prepare($sql);
$statement->bindParam("bar", $foo->bar);
$statement->execute();
$foo->id = $this->db->lastInsertId();
}
}
}

//Insert
$foo = new Foo();
$foo->bar = 'baz';
$mapper = new FooMapper($db);
$mapper->saveFoo($foo);




В данном случае, класс Foo намного проще и должен беспокоиться только о своей бизнес-логике. Он не только не должен сохранять собственные данные, он даже не знает и не заботится о том, все ли его данные были сохранены.

Преимущества Data Mapper-а





  • Каждый объект имеет свою зону ответственности, тем самым следую принципам SOLID и сохраняя каждый объект простым и по существу.

  • Бизнес-логика и сохранение данных связаны слабо, и если вы хотите сохранять данные в XML-файл или какой-нибудь другой формат, вы можете просто написать новый Mapper, не притрагиваясь к доменному объекту.




Недостатки Data Mapper-а





  • Вам придется гораздо больше думать, перед тем как написать код.

  • В итоге у вас больше объектов в управлении, что немного усложняет код и его отладку.




Сервис-объекты




При использовании шаблона проектирования Data Mapper, вызывающий код должен выбрать Mapper и бизнес-объект и связать их вместе. Если это код вызова в контроллере, то в конечном счете ваша модель «утекает» в контроллер, что может вызвать большие проблемы при поддержке и юнит-тестировании. Эта проблема может быть решена путем введения объекта-сервиса. Сервис является воротами между контроллером и моделью и связывает доменный объект с Mapper-ом по мере необходимости.

Следует помнить, что M в MVC, представляет собой слой абстракции модели, а не объект модели. Так может быть несколько типов объектов в одной модели (в приведенном выше примере, у вас может быть объект сервиса, доменный объект и объект Mapper-а, выступающие в роли единой модели). С другой стороны, если вы используете модели Active Record, ваша модель может быть представлена лишь одним объектом.


Варианты использования




Объекты Active Record исторически были очень популярны из-за того, что они проще, легче в понимании и быстрее в написании, поэтому многие фреймворки и ORM используют Active Record по умолчанию.

Если вы уверены, что вам никогда не понадобиться менять слой сохранения данных (если вы имеете дело с объектом, который представляет из себя INI-файл, например), или вы имеете дело с очень простыми объектами, в которых не так много бизнес-логики, или просто предпочитаете держать все в небольшом количестве классов, тогда шаблон Active Record это то, что вам нужно.


Использование Data Mapper-а хотя и ведет к более чистому, простому в тестировании и поддержке коду, и обеспечивает большую гибкость, — цена этому, — повышение сложности. Если вы еще не пробовали его использовать, то дайте ему шанс, — вам должно понравиться.


Это перевод статьи Рассела Волкера.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Комментариев нет:

Отправить комментарий