Evolucionando hacia una capa de persistencia

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

Uno de los patrones de diseño más confusos es la persistencia. La necesidad de que una aplicación persista en su estado interno y en los datos es tan grande que es probable que existan decenas, sino cientos, de diferentes tecnologías para abordar este problema. Desafortunadamente, ninguna tecnología es una bala mágica. Cada aplicación, y a veces cada componente de la aplicación, es única a su manera, por lo tanto, requiere una solución única.

En este tutorial, le enseñaré algunas de las mejores prácticas para ayudarlo a determinar qué enfoque tomar, cuando trabaje en aplicaciones futuras. Discutiré brevemente algunas inquietudes y principios de diseño de alto nivel, seguidos de una vista más detallada sobre el patrón de diseño Active Record, combinado con unas pocas palabras sobre el patrón de diseño Table Data Gateway.

Por supuesto, no solo te enseñaré la teoría detrás del diseño, sino que también te guiaré a través de un ejemplo que comienza como un código aleatorio y se transforma en una solución de persistencia estructurada.

Dos cuentos de una sola aplicación

La base de datos es para datos, no para código

Hoy, ningún programador puede entender este sistema arcaico.

El proyecto más antiguo en el que tengo que trabajar comenzó en el año 2000. En aquel entonces, un equipo de programadores comenzó un nuevo proyecto evaluando diferentes requisitos, pensando en las cargas de trabajo que la aplicación tendría que manejar, probando diferentes tecnologías y llegando a una conclusión: todos el código PHP de la aplicación, excepto el archivo index.php, debe residir en una base de datos MySQL. Su decisión puede sonar escandalosa hoy, pero fue aceptable hace doce años (OK ... tal vez no).

Comenzaron por crear sus tablas base, y luego otras tablas para cada página web. La solución funcionó ... por un tiempo. Los autores originales sabían cómo mantenerlo, pero luego cada autor se fue uno a uno, dejando el código base en manos de otros recién llegados.

Hoy, ningún programador puede entender este sistema arcaico. Todo comienza con una consulta MySQL de index.php. El resultado de esa consulta devuelve un código PHP que ejecuta aún más consultas. El escenario más simple implica al menos cinco tablas de base de datos. Naturalmente, no hay pruebas o especificaciones. Modificar algo es un no-go, y simplemente tenemos que reescribir todo el módulo si algo sale mal.

Los desarrolladores originales ignoraron el hecho de que una base de datos solo debería contener datos, no lógica comercial o presentación. Mezclaron el código PHP y HTML con MySQL e ignoraron los conceptos de diseño de alto nivel.

El HTML es solo para presentación y presentación

Todas las aplicaciones deben concentrarse en respetar un diseño limpio y de alto nivel.

Con el paso del tiempo, los nuevos programadores necesitaron agregar características adicionales al sistema mientras que, al mismo tiempo, corrigieron viejos errores. No había forma de continuar usando las tablas de MySQL para todo, y todos los involucrados en mantener el código coincidieron en que su diseño era terriblemente defectuoso. De modo que los nuevos programadores evaluaron diferentes requisitos, pensaron en las cargas de trabajo que la aplicación debería manejar, probaron diferentes tecnologías y llegaron a una conclusión: decidieron mover la mayor cantidad de código posible a la presentación final. Una vez más, esta decisión puede sonar escandalosa hoy, pero fue años luz del diseño escandaloso anterior.

Los desarrolladores adoptaron un marco de plantillas y basaron la aplicación en torno a él, comenzando cada nueva característica y módulo con una nueva plantilla. Fue fácil; la plantilla era descriptiva y sabían dónde encontrar el código que realiza una tarea específica. Pero así es como terminaron con los archivos de plantilla que contienen el lenguaje específico del dominio (DSL) del motor, HTML, PHP y, por supuesto, las consultas de MySQL.

Hoy, mi equipo solo mira y se pregunta. Es un milagro que muchas de las vistas realmente funcionen. Puede tomar una gran cantidad de tiempo solo para determinar cómo se obtiene la información de la base de datos a la vista. Al igual que su predecesor, ¡todo es un gran desastre!

Esos desarrolladores ignoraron el hecho de que una vista no debería contener lógica comercial o de persistencia. Mezclaron el código PHP y HTML con MySQL e ignoraron los conceptos de diseño de alto nivel.

Diseño de aplicaciones de alto nivel

Un simulacro es un objeto que actúa como su contraparte real, pero no ejecuta el código real.

Todas las aplicaciones deben concentrarse en respetar un diseño limpio y de alto nivel. Esto no siempre se puede lograr, pero debe ser una alta prioridad. Un buen diseño de alto nivel tiene una lógica empresarial bien aislada. La creación, persistencia y entrega de objetos están fuera del núcleo y las dependencias apuntan solo hacia la lógica de negocios.

Aislar la lógica de negocios abre la puerta a grandes posibilidades, y todo se convierte en algo así como un complemento, si las dependencias externas siempre apuntan hacia la lógica de negocios. Por ejemplo, puede cambiar la pesada base de datos MySQL con una base de datos liviana SQLite3.

Imagine poder abandonar su marco MVC actual y reemplazarlo por otro, sin tocar la lógica comercial.
Imagine entregar los resultados de su aplicación a través de una API de terceros y no a través de HTTP, o cambiar cualquier tecnología de terceros que use hoy (excepto el lenguaje de programación, por supuesto) sin tocar la lógica comercial (o sin mucha molestia).
Imagina hacer todos estos cambios y tus pruebas aún pasarían.

Implementando una solución de trabajo para persistir en una publicación de blog

Para identificar mejor los problemas con un diseño malo, aunque funcional, comenzaré con un simple ejemplo de, lo adivinaron, un blog. A lo largo de este tutorial, seguiré algunos principios de desarrollo impulsados por pruebas (TDD) y haré que las pruebas sean fácilmente comprensibles, incluso si no tienes experiencia con TDD. Imaginemos que usa un framework MVC. Al guardar una publicación de blog, un controlador llamado BlogPost ejecuta un método save(). Este método se conecta a una base de datos SQLite para almacenar una publicación de blog en la base de datos.

Vamos a crear una carpeta, llamada Datos Data en la carpeta de nuestro código y busque ese directorio en la consola. Crea una base de datos y una tabla, como esta:

$ sqlite3 MyBlog
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table BlogPosts (
  title varchar(120) primary key,
	content text,
	published_timestamp timestamp);

Nuestro método save() obtiene los valores del formulario como una matriz, llamada $data:

class BlogPostController {

	function save($data) {
		$dbhandle = new SQLite3('Data/MyBlog');

		$query = 'INSERT INTO BlogPosts VALUES("' . $data['title'] . '","' . $data['content'] . '","' . time(). '")';
		$dbhandle->exec($query);
	}

}

Este código funciona, y puedes verificarlo llamándolo desde otra clase, pasando una matriz predefinida $data, como esta:

$this->object = new BlogPostController;

$data['title'] = 'First Post Title';
$data['content'] = 'Some cool content for the first post';
$data['published_timestamp'] = time();

$this->object->save($data);

El contenido de la variable $data fue efectivamente guardado en la base de datos:

1	sqlite> select * from BlogPosts;
2	First Post Title\|Some cool content for the first post\|1345665216

Pruebas de caracterización

La herencia es el tipo más fuerte de dependencia.

Una prueba de caracterización describe y verifica el comportamiento actual del código preexistente. Se utiliza con mayor frecuencia para caracterizar el código heredado, y hace que la refacturación de ese código sea mucho más fácil.

Una prueba de caracterización puede probar un módulo, una unidad, o recorrer todo el camino desde la interfaz de usuario a la base de datos; todo depende de lo que queremos probar. En nuestro caso, dicha prueba debe ejercer el controlador y verificar el contenido de la base de datos. Esta no es una prueba de unidad, funcional o de integración típica, y generalmente no se puede asociar con ninguno de esos niveles de prueba.

Las pruebas de caracterización son una red de seguridad temporal, y normalmente las eliminamos después de que el código se refactoriza adecuadamente y se prueba la unidad. Aquí hay una implementación de una prueba, colocada en la carpeta Prueba Test :

require_once '../BlogPostController.php';

class BlogPostControllerTest extends PHPUnit_Framework_TestCase {
	private $object;
	private $dbhandle;

	function setUp() {
		$this->object = new BlogPostController;
		$this->dbhandle = new SQLite3('../Data/MyBlog');
	}


	function testSave() {
		$this->cleanUPDatabase();

		$data['title'] = 'First Post Title';
		$data['content'] = 'Some cool content for the first post';
		$data['published_timestamp'] = time();
		$this->object->save($data);

		$this->assertEquals($data, $this->getPostsFromDB());

	}

	private function cleanUPDatabase() {
		$this->dbhandle->exec('DELETE FROM BlogPosts');
	}

	private function getPostsFromDB() {
		$result = $this->dbhandle->query('SELECT * FROM BlogPosts');
		return $result->fetchArray(SQLITE3_ASSOC);
	}

}

Esta prueba crea un nuevo objeto controlador y ejecuta su método save(). La prueba luego lee la información de la base de datos y la compara con la matriz $data[] predefinida. Preformamos esta comparación utilizando el método $this->assertEquals(), una afirmación que supone que sus parámetros son iguales. Si son diferentes, la prueba falla. Además, limpiamos la tabla de la base de datos BlogPosts cada vez que ejecutamos la prueba.

El código heredado es código no probado. - Michael Feathers

Con nuestra prueba en funcionamiento, limpiemos un poco el código. Abra la base de datos con el nombre completo del directorio y use sprintf() para componer la cadena de consulta. Esto da como resultado un código mucho más simple:

class BlogPostController {

	function save($data) {
		$dbhandle = new SQLite3(__DIR__ . '/Data/MyBlog');

		$query = sprintf('INSERT INTO BlogPosts VALUES ("%s","%s","%s")', $data['title'], $data['content'], time());

		$dbhandle->exec($query);
	}

}

El patrón Table Data Gateway

Reconocemos que nuestro código debe trasladarse desde el controlador a la lógica de negocios y la capa de persistencia, y el patrón de puerta de enlace puede ayudarnos a comenzar a recorrer esa ruta. Aquí está el método revisado testSave():

	function testItCanPersistABlogPost() {
		$data = array('title' => 'First Post Title', 'content' => 'Some content.', 'timestamp' => time());
		$blogPost = new BlogPost($data['title'], $data['content'], $data['timestamp']);

		$mockedPersistence = $this->getMock('SqlitePost');
		$mockedPersistence->expects($this->once())->method('persist')->with($blogPost);

		$controller = new BlogPostController($mockedPersistence);
		$controller->save($data);
	}

Esto representa cómo queremos usar el método save() en el controlador. Esperamos que el controlador llame a un método llamado persist($blogPostObject) en el objeto de la puerta de enlace. Cambiemos nuestro BlogPostController para hacer eso:

class BlogPostController {
	private $gateway;

	function __construct(Gateway $gateway = null) {
		$this->gateway = $gateway ? : new SqlitePost();
	}

	function save($data) {
		$this->gateway->persist(new BlogPost($data['title'], $data['content'], $data['timestamp']));
	}

}

Un buen diseño de alto nivel tiene una lógica bien aislada.

¡Bonito! Nuestro BlogPostController se volvió mucho más simple. Utiliza la puerta de enlace (ya sea suministrada o instanciada) para persistir los datos llamando a su método persist(). No hay absolutamente ningún conocimiento sobre cómo persisten los datos; la lógica de persistencia se volvió modular.

En la prueba anterior, creamos el controlador con un objeto de persistencia falso, asegurando que los datos nunca se escriban en la base de datos cuando se ejecuta la prueba. En el código de producción, el controlador crea su propio objeto persistente para persistir los datos utilizando un objeto SqlitePost. Un simulacro es un objeto que actúa como su equivalente real, pero no ejecuta el código real.

Ahora recuperemos una publicación de blog del almacén de datos. Es tan fácil como guardar datos, pero tenga en cuenta que modifiqué un poco la prueba.

require_once '../BlogPostController.php';
require_once '../BlogPost.php';

require_once '../SqlitePost.php';

class BlogPostControllerTest extends PHPUnit_Framework_TestCase {
		private $mockedPersistence;
		private $controller;
		private $data;

	function setUp() {
		$this->mockedPersistence = $this->getMock('SqlitePost');
		$this->controller = new BlogPostController($this->mockedPersistence);
		$this->data = array('title' => 'First Post Title', 'content' => 'Some content.', 'timestamp' => time());
	}

	function testItCanPersistABlogPost() {
		$blogPost = $this->aBlogPost();
		$this->mockedPersistence->expects($this->once())->method('persist')->with($blogPost);

		$this->controller->save($this->data);
	}

	function testItCanRetrievABlogPostByTitle() {
		$expectedBlogpost = $this->aBlogPost();
		$this->mockedPersistence->expects($this->once())
				->method('findByTitle')->with($this->data['title'])
				->will($this->returnValue($expectedBlogpost));

		$this->assertEquals($expectedBlogpost, $this->controller->findByTitle($this->data['title']));
	}

	public function aBlogPost() {
		return new BlogPost($this->data['title'], $this->data['content'], $this->data['timestamp']);
	}

}

Y la implementación en BlogPostController es solo un método de declaración:

1	function findByTitle($title) {
2	return $this->gateway->findByTitle($title);
3	}

¿No es genial? La clase BlogPost ahora es parte de la lógica empresarial (recuerde el esquema de diseño de alto nivel de arriba). La UI / MVC crea objetos BlogPost y utiliza implementaciones concretas de Gateway para conservar los datos. Todas las dependencias apuntan a la lógica de trabajo.

Solo queda un paso: crear una implementación concreta de Gateway. La siguiente es la clase SqlitePost:

require_once 'Gateway.php';

class SqlitePost implements Gateway {
	private $dbhandle;

	function __construct($dbhandle = null) {
		$this->dbhandle = $dbhandle ? : new SQLite3(__DIR__ . '/Data/MyBlog');
	}

	public function persist(BlogPost $blogPost) {
		$query = sprintf('INSERT INTO BlogPosts VALUES ("%s","%s","%s")', $blogPost->title, $blogPost->content, $blogPost->timestamp);
		$this->dbhandle->exec($query);
	}

	public function findByTitle($title) {
		$SqliteResult = $this->dbhandle->query(sprintf('SELECT * FROM BlogPosts WHERE title = "%s"', $title));
		$blogPostAsString = $SqliteResult->fetchArray(SQLITE3_ASSOC);
		return new BlogPost($blogPostAsString['title'], $blogPostAsString['content'], $blogPostAsString['timestamp']);
	}
}

Nota: La prueba para esta implementación también está disponible en el código fuente, pero, debido a su complejidad y duración, no la incluí aquí.

Avanzando hacia el patrón de registro activo

Active Record es uno de los patrones más controvertidos. Algunos lo abrazan (como Rails y CakePHP), y otros lo evitan. Muchas aplicaciones de mapeo relacional de objetos (ORM) usan este patrón para guardar objetos en tablas. Aquí está su esquema:

Como puede ver, los objetos basados en Active Record pueden persistir y recuperarse. Esto generalmente se logra al extender una clase ActiveRecordBase, una clase que sabe cómo trabajar con la base de datos.

El mayor problema con Active Record es la extensión de la dependencia. Como todos sabemos, la herencia es el tipo más fuerte de dependencia, y lo mejor es evitarla la mayor parte del tiempo.

Antes de ir más allá, aquí es donde estamos ahora:

La interfaz de puerta de enlace pertenece a la lógica de negocios, y sus implementaciones concretas pertenecen a la capa de persistencia. Nuestro BlogPostController tiene dos dependencias, ambas apuntan hacia la lógica comercial: la puerta de enlace SqlitePost y la clase BlogPost.

Ir por registro activo

Hay muchos otros patrones, como el patrón de proxy, que están estrechamente relacionados con la persistencia.

Si tuviéramos que seguir el patrón Active Record exactamente como lo presenta Martin Fowler en su libro de 2003, Patterns of Enterprise Application Architecture, entonces tendríamos que mover las consultas SQL a la clase BlogPost. Esto, sin embargo, tiene el problema de violar tanto el Principio de Inversión de Dependencia como el Principio Abierto Cerrado. El Principio de Inversión de Dependencia establece que:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.
Las abstracciones no deberían depender de detalles. Los detalles deben depender de las abstracciones.

Y el Principio Abierto Cerrado declara: las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión, pero cerradas para su modificación. Tomaremos un enfoque más interesante e integraremos el portal en nuestra solución Active Record.

Si intenta hacer esto por su cuenta, probablemente ya se haya dado cuenta de que agregar el patrón de registro activo al código arruinará las cosas. Por esta razón, tomé la opción de deshabilitar el controlador y las pruebas de SqlitePost para concentrarme solo en la clase BlogPost. Los primeros pasos son: haga que BlogPost se cargue a sí mismo estableciendo su constructor como privado y conéctelo a la interfaz de la puerta de enlace. Aquí está la primera versión del archivo BlogPostTest:

require_once '../BlogPost.php';
require_once '../InMemoryPost.php';
require_once '../ActiveRecordBase.php';

class BlogPostTest extends PHPUnit_Framework_TestCase {


	function testItCanConnectPostToGateway() {
		$blogPost = BlogPost::load();
		$blogPost->setGateway($this->inMemoryPost());
		$this->assertEquals($blogPost->getGateway(), $this->inMemoryPost());
	}

	function testItCanCreateANewAndEmptyBlogPost() {
		$blogPost = BlogPost::load();
		$this->assertNull($blogPost->title);
		$this->assertNull($blogPost->content);
		$this->assertNull($blogPost->timestamp);
		$this->assertInstanceOf('Gateway', $blogPost->getGateway());
	}

	private function inMemoryPost() {
		return new InMemoryPost();
	}

}

Comprueba que una publicación de blog se inicializó correctamente y que puede tener una puerta de enlace si está configurada. Es una buena práctica usar múltiples aseveraciones cuando todos prueban el mismo concepto y lógica.

Nuestra segunda prueba tiene varias afirmaciones, pero todas se refieren al mismo concepto común de publicación de blog vacía. Por supuesto, la clase BlogPost también se ha modificado:

class BlogPost {
	private $title;
	private $content;
	private $timestamp;
	private static $gateway;

	private function __construct($title = null, $content = null, $timestamp = null) {
		$this->title = $title;
		$this->content = $content;
		$this->timestamp = $timestamp;
	}

	function __get($name) {
		return $this->$name;
	}

	function setGateway($gateway) {
		self::$gateway = $gateway;
	}

	function getGateway() {
		return self::$gateway;
	}

	static function load() {
		if(!self::$gateway) self::$gateway = new SqlitePost();
		return new self;
	}
}

Ahora tiene un método load() que devuelve un nuevo objeto con una puerta de enlace válida. A partir de este momento, continuaremos con la implementación de un método load($title) para crear un nuevo BlogPost con información de la base de datos. Para una prueba fácil, implementé una clase InMemoryPost para la persistencia. Simplemente mantiene una lista de objetos en la memoria y devuelve la información como se desee:

class InMemoryPost implements Gateway {
	private $blogPosts = array();

	public function findByTitle($blogPostTitle) {
		return array(
			'title' => $this->blogPosts[$blogPostTitle]->title,
			'content' => $this->blogPosts[$blogPostTitle]->content,
			'timestamp' => $this->blogPosts[$blogPostTitle]->timestamp);

	}

	public function persist(BlogPost $blogPostObject) {
		$this->blogPosts[$blogPostObject->title] = $blogPostObject;
	}
}

Luego, me di cuenta de que la idea inicial de conectar BlogPost a una puerta de enlace a través de un método separado era inútil. Entonces, modifiqué las pruebas, en consecuencia:

class BlogPostTest extends PHPUnit_Framework_TestCase {

	function testItCanCreateANewAndEmptyBlogPost() {
		$blogPost = BlogPost::load();
		$this->assertNull($blogPost->title);
		$this->assertNull($blogPost->content);
		$this->assertNull($blogPost->timestamp);
	}

	function testItCanLoadABlogPostByTitle() {
		$gateway = $this->inMemoryPost();
		$aBlogPosWithData = $this->aBlogPostWithData($gateway);

		$gateway->persist($aBlogPosWithData);

		$this->assertEquals($aBlogPosWithData, BlogPost::load('some_title', null, null, $gateway));
	}

	private function inMemoryPost() {
		return new InMemoryPost();
	}

	private function aBlogPostWithData($gateway = null) {
		return BlogPost::load('some_title', 'some content', '123', $gateway);
	}

}

Como puede ver, cambié radicalmente la forma en que se usa BlogPost.

class BlogPost {
	private $title;
	private $content;
	private $timestamp;

	private function __construct($title = null, $content = null, $timestamp = null) {
		$this->title = $title;
		$this->content = $content;
		$this->timestamp = $timestamp;
	}

	function __get($name) {
		return $this->$name;
	}

	static function load($title = null, $content = null, $timestamp = null, $gateway = null) {
		$gateway = $gateway ? : new SqlitePost();

		if(!$content) {
			$postArray = $gateway->findByTitle($title);
			if ($postArray) return new self($postArray['title'], $postArray['content'], $postArray['timestamp']);
		}

		return new self($title, $content, $timestamp);
	}
}

El método load() comprueba el parámetro $content para un valor y crea un nuevo BlogPost si se proporcionó un valor. Si no, el método intenta encontrar una publicación de blog con el título dado. Si se encuentra una publicación, se devuelve; si no hay ninguno, el método crea un objeto de BlogPost vacío.

Para que este código funcione, también tendremos que cambiar el funcionamiento de la puerta de enlace. Nuestra implementación necesita devolver una matriz asociativa con elementos title, content, y timestamp en lugar del objeto en sí. Esta es una convención que he elegido. Puede encontrar otras variantes, como una matriz simple, más atractiva. Aquí están las modificaciones en SqlitePostTest:

	function testItCanRetrieveABlogPostByItsTitle() {
		[...]
		//we expect an array instead of an object
		$this->assertEquals($this->blogPostAsArray, $gateway->findByTitle($this->blogPostAsArray['title']));
	}
	private function aBlogPostWithValues() {
		//we use static load instead of constructor call
		return $blogPost = BlogPost::load(
				$this->blogPostAsArray['title'],
				$this->blogPostAsArray['content'],
				$this->blogPostAsArray['timestamp']);
	}

Y los cambios de implementación son:

	public function findByTitle($title) {
		$SqliteResult = $this->dbhandle->query(sprintf('SELECT * FROM BlogPosts WHERE title = "%s"', $title));
		//return the result directly, don't construct the object
		return $SqliteResult->fetchArray(SQLITE3_ASSOC);
	}

Casi terminamos. Agregue un método persist() al BlogPost y llame a todos los métodos recién implementados desde el controlador. Aquí está el método persist() que simplemente usará el método persist() de la puerta de enlace:

1	private function persist() {
2	$this->gateway->persist($this);
3	}

Y el controlador:

class BlogPostController {

	function save($data) {
		$blogPost = BlogPost::load($data['title'], $data['content'], $data['timestamp']);
		$blogPost->persist();
	}

	function findByTitle($title) {
		return BlogPost::load($title);
	}

}

El BlogPostController se volvió tan simple que eliminé todas sus pruebas. Simplemente llama al método persist() del objeto BlogPost. Naturalmente, querrá agregar pruebas si, y cuándo, tiene más código en el controlador. La descarga del código todavía contiene un archivo de prueba para BlogPostController, pero se comenta su contenido.

Conclusión

Esto es sólo la punta del iceberg.

Has visto dos implementaciones de persistencia diferentes: los patrones de puerta de enlace y registro activo. A partir de este punto, puede implementar una clase abstracta de ActiveRecordBase para extender para todas sus clases que necesitan persistencia. Esta clase abstracta puede usar diferentes puertas de enlace para persistir en los datos, y cada implementación puede incluso usar una lógica diferente para satisfacer sus necesidades.

Pero esto es solo la punta del iceberg. Hay muchos otros patrones, como el patrón de proxy, que están estrechamente relacionados con la persistencia; cada patrón funciona para una situación particular. Recomiendo que siempre implemente la solución más simple primero, y luego implemente otro patrón cuando sus necesidades cambien.

Espero que hayan disfrutado este tutorial, y espero ansiosamente sus opiniones e implementaciones alternativas a mi solución en los comentarios a continuación.