Active Record
Escrito por nestor.salceda hace 1 años
bajo una licencia de Creative Commons
1533 visitas. Etiquetas: designpatterns
Definición:
Es un objeto que representa una fila en una tabla de una base de datos, encapsula su acceso a la base de datos y añade lógica de negocio.
Es la aproximación más obvia, poniendo el acceso a la base datos en el propio objeto de negocio. De este modo es evidente como manipular la persistencia a través de el mismo.
Explicación:
Gran parte de este patrón viene de un Domain Model y esto significa que las clases están muy cercanas a la representación en la base de datos. Cada Active Record es responsable de si mismo, tanto en lo relacionado con persistencia como en su lógica de negocio.
Generalmente proveerá métodos como:
- Construir una instancia de la clase desde una fila de un resultado de una consulta.
- Construir una nueva instancia para insertarlo posteriormente en la tabla.
- Un método estático para buscar.
- Actualización e inserción en la tabla.
- Getter y Setters o bien Propiedades.
- Implementará algunas piezas de la lógica de negocio.
Aunque no todos son totalmente necesarios, ni mucho menos. Sirva el caso del método estático de búsqueda que los puedes extraer a otra clase, si así es necesario y te aclaras mejor, esto viene dado por su acoplamiento a la base de datos relacional que habrá por detrás.
Escenarios recomendados:
Muchos patrones, no dan buenos ejemplos prácticos o buenas notas de cuándo debe ser usado (se puede ver el hilo Sobreingenieria :P), y en este caso se puede dar una aproximación más concreta.
- Lógica que no es muy compleja. Tiene la ventaja de ser un patrón muy muy simple.
- Solamente trabaja bien cuando el esquema coincide con la estructura del objeto. Es algo isomorfico. En el caso de que no se dé esta condición puede que sea necesario que pienses en alguna otra solución más poderosa.
- El acoplamiento a la base de datos es bastante alto. Esto puede ser una desventaja y puede inducir problemas en el futuro a la hora de refactorizar.
Trucos:
- Puedes usarlo sobre una vista también, y así te quitas algún dolor a la hora de generar reportes.
Discusión en la implementación y referencias:
Es un patrón que se ha vuelto muy popular desde que conocemos el ActiveRecord de Ruby on Rails, dado que este framework lo usa. Y en este caso es especialmente poderoso, y nosotros podemos implementarlo con un truquito :)
A la hora de acceder a los diferentes miembros que sean claves foráneas, podemos hacer que se descargue la información cuando accedemos a la propiedad:
public class Book {
Author author;
public Author Author {
get {
if (author == null)
author = GetAuthorFromDatabase ();
return author;
}
}
}Y así poder navegar entre las relaciones que existan (es necesario tener la clave primaria del autor en algún sitio para poder descargarlo, claro está).
También puede ser conveniente nombrar el ActiveRecord de Castle Project.
Resumiendo y para finalizar ya, sobre todo de este patrón se recalca la extremada sencillez y eso puede hacerlo no válido para programas muy complejos o bien para código legacy ya existente. Para más información, lo podeis encontrar en Patterns of Enterprise Applications Architecture de Martin Fowler o bien por internet, se puede encontrar más información.
Artículos Relacionados
- Introducción a Google App Engine
- Principales vulnerabilidades en aplicaciones web
- Sencilla implementación de ActiveRecord en Python
- Sonar: Métricas en un proyecto Maven
- Siena: persistencia en Java sencilla y escalable
Grupos relacionados
Entusiasta de la construcción de software, me gusta todo: Tecnologias, Patrones de Diseño, Metodologías Ágiles, Algoritmia ... Entusiasta del Open-Source y colaborador de Gendarme y del proyecto Mono.
6 comentarios en "Active Record"
TeMiL escribió
hace 1 años
nestor.salceda escribió
hace 1 años
Sip, el DAO (Mapper) es un patrón muy común, especialmente cuando se usa con Layers. Desde luego, si la lógica de inserciones es más compleja, desde luego que es una buena opción para tenerla en la cabeza, o bien refactorizar :)
Gracias por el comentario TeMiL :)
Luix escribió
hace 1 años
Puede aportar mucha transparencia en el manejo de la información, al saltar de Modelo a Datos sin pasar por el Control (bueno, estoy suponiendo un patrón típico MVC), pero si se realizan numerosas modificaciones en las propiedades de los objetos, ¿no genera demasiadas transacciones a la base de datos?
nestor.salceda escribió
hace 1 años
Si y no, depende ya un poco de la implementación.
En caso de que por cada setter, se ejecute el update a la base de datos; pues esto generará actividad en la base de datos.
Se puede hacer también que en ningun setter se ejecute update, y al final hacer una actualización de todo el objeto. Esto da una granularidad un más fina, y el rendimiento es mejor (pero no hay que olvidar hacer el commit () o el put () o el update () para actualizar el estado).
class Book {
private int id_author;
private Author author;
public Author Author {
get {
if (author == null)
author = GetAuthorFromDatabase (id_author);
return author;
}
set {
author = value;
if (author == null)
id_author = author.id;
}
}
}
class Client {
public static void Main () {
Book book = Book.FindByTitle ("Trolling Howto");
Author author = new Author ("Néstor Salceda");
author.put ();
//Hemos guardado el autor.
book.Author = author;
//Cambiamos el autor del libro
book.put ();
//Actualizamos el libro.
}
}Gracias por el comentario Luix :)
Luix escribió
hace 1 años
Aham. ¿Y en el caso de un get? Por lo que leo en el código de tu clase Book, parece que la primera vez se carga de la BD y luego se almacena en memoria para futuros accesos, con lo cual se limita el acceso a BD en estos casos :) y se mejora en eficiencia.
Entonces, el intríngulis del ActiveRecord estaría en las escrituras (o actualizaciones). ¿Me equivoco?
nestor.salceda escribió
hace 1 años
Joer, que patinazo el mio, acabo de ver la pregunta ahora. Mil disculpas por ello.
En efecto, con el get se trata de hacer una carga perezosa.
Hombre, no realmente, el intringulis del Active Record te dice como organizar el código, pero no te dice que debas hacer cargas perezosas; eso es algo que se me ha ocurrido que puede estar bien.
En el caso de una actualización, si estamos actualizando un campo que es una clave foránea, por ejemplo cambiar el id del autor, pues podemos hacer la edición, mandar el update a la base de datos (o bien esperar un ratillo, incluso) y anular el campo que tengamos con el autor y asi la próxima vez se conseguirá el nuevo.
Gracias por el comentario Luix !
© Copyright 2008-2009 debug_mode=ON | Aviso legal | Contacto | FAQ | ¿Quiénes somos?
|
#1
interesante :)
siempre he utilizado el patron DAO y lo ultimo fue ayudandome con la herramienta Web Service Software Factory que me facilita la creacion de las capas de mi aplicacion web, utilizando BusinessLogic, DataAccess y BusinessEntities ^^