¿Por qué debería abstraer mi capa de datos?

StackOverflow https://stackoverflow.com/questions/5314697

Pregunta

Los principios de OOP fueron difíciles de comprender porque por alguna razón nunca pude aplicarlos al desarrollo web. A medida que desarrollaba más y más proyectos, comencé a comprender cómo algunas partes de mi código podrían usar ciertos patrones de diseño para que sean más fáciles de leer, reutilizar y mantener para que comencé a usarlo cada vez más.

Lo único que todavía no puedo comprender es por qué debería abstraer mi capa de datos. Básicamente, si necesito imprimir una lista de elementos almacenados en mi DB al navegador, hago algo en la línea de:

$sql = 'SELECT * FROM table WHERE type = "type1"';'
$result = mysql_query($sql);

while($row = mysql_fetch_assoc($result))
{
    echo '<li>'.$row['name'].'</li>';
}

Estoy leyendo todos estos tos o artículos que predican sobre la grandeza de PDO, pero no entiendo por qué. Parece que no estoy guardando ningún LOC y no veo cómo sería más reutilizable porque todas las funciones que llamo anteriormente parecen estar encapsuladas en una clase, pero hacen exactamente lo mismo. La única ventaja que veo para PDO son las declaraciones preparadas.

No digo que la abstracción de datos sea algo malo, estoy haciendo estas preguntas porque estoy tratando de diseñar mis clases actuales correctamente y deben conectarse a un DB, así que pensé que haría esto el Correcto camino. Tal vez solo estoy leyendo artículos malos sobre el tema :)

¡Realmente agradecería cualquier consejo, enlaces o ejemplos concretos de la vida real sobre el tema!

¿Fue útil?

Solución

Una de las otras ventajas de abstraer la capa de datos es depender menos de la base de datos subyacente.

Con su método, el día que desea usar algo más que MySQL o su cambio de nombres de columna o la API PHP sobre el cambio MySQL, tendrá que reescribir mucho código.

Si toda la parte de acceso a la base de datos se abstrae perfectamente, los cambios necesarios serán mínimos y restringirán a algunos archivos en lugar de todo el proyecto.

También es mucho más fácil reutilizar el código con respecto a la inyección SQL u otras funciones de utilidad si el código está centralizado en un solo lugar.

Finalmente, es más fácil hacer pruebas unitarias si todo va a través de algunas clases que en cada página de su proyecto.

Por ejemplo, en un proyecto mío reciente (lo siento, no es posible compartir código), las funciones relacionadas con MySQL solo se llaman en una clase. Todo, desde la generación de consultas hasta la instanciación de objetos, se hace aquí. Por lo tanto, es muy para mí cambiar a otra base de datos o reutilizar esta clase en otro lugar.

Otros consejos

Piense en abstraer la capa de datos como una forma de ahorrar tiempo en el futuro.

Usando su ejemplo. Digamos que cambió los nombres de las tablas. Tendría que ir a cada archivo donde tenga un SQL usando esa tabla y editarlo. En el mejor de los casos, era una cuestión de búsqueda y reemplazo de los archivos N. Podría haber ahorrado mucho tiempo y minimizar el error si solo tuviera que editar un archivo, el archivo que tenía todos sus métodos SQL.

Lo mismo se aplica a los nombres de la columna.

Y esto solo está considerando el caso en el que cambia el nombre de cosas. También es bastante posible cambiar por completo los sistemas de bases de datos. Es posible que su SQL no sea compatible entre SQLite y MySQL, por ejemplo. Tendría que ir y editar, una vez más, muchos archivos.

La abstracción le permite desacoplar una parte de la otra. En este caso, puede realizar cambios en la parte de la base de datos sin afectar la parte de la vista.

Para proyectos muy pequeños, esto podría ser más problemas de lo que vale. E incluso entonces, aún debe hacerlo, al menos para acostumbrarse.

No soy una persona de PHP, pero esta es una pregunta más general, así que aquí va.

Probablemente esté construyendo algo pequeño, a veces, aunque incluso algo pequeño/medio debería tener una capa de datos abstractos para que pueda crecer mejor.

El punto es hacer frente a CAMBIO

Piense en esto, tiene un pequeño sitio web de redes sociales. Piense en los datos que almacenará, detalles de perfil, imágenes, amigos, mensajes. Para cada uno de estos tendrás páginas como pictures.php?&uid=xxx.

Luego tendrá una pequeña pieza de SQL abofeteada allí con el código MySQL. ¿Ahora piense en lo fácil/difícil que sería cambiar esto? ¿Cambiarías de 5 a 10 páginas? Cuando hagas esto, probablemente te equivocarás varias veces antes de probarlo a fondo.

Ahora, piense en Facebook. Piense en la cantidad de páginas que habrá, ¿cree que será más fácil cambio ¿Una línea de SQL en cada página?

Cuando abstrae el acceso de datos correctamente:

  1. Está en un solo lugar, es más fácil cambiar.
  2. Por lo tanto, es más fácil de probar.
  3. Es más fácil de reemplazar. (Piense en lo que tendría que hacer si tuviera que cambiar a otra base de datos)

Espero que esto ayude

En mi opinión, el acceso a los datos es uno de los aspectos más importantes para separar / abstraer del resto de su código.

Separar varias 'capas' tiene varias ventajas.

1) Organiza cuidadosamente su base de código. Si tiene que hacer un cambio, sabrá inmediatamente dónde se debe hacer el cambio y dónde encontrar el código. Puede que esto no sea un gran problema si está trabajando en un proyecto por su cuenta, pero con un equipo más grande, los beneficios pueden volverse evidentes rápidamente. Este punto es en realidad bastante trivial, pero lo agregué de todos modos. La verdadera razón es el número 2 ..

2) Debe tratar de separar las cosas que podrían necesitar cambiar independientemente entre sí. En su ejemplo específico, es concebible que desee cambiar la lógica de acceso DB / Data sin afectar la interfaz de usuario. O bien, es posible que desee cambiar la interfaz de usuario sin afectar el acceso a los datos. Estoy seguro de que puede ver cómo esto se hace imposible si el código se mezcla entre sí.

Cuando su capa de acceso de datos tiene una interfaz muy definida, puede cambiar sus trabajos internos como desee, y siempre que aún se adhiera a la interfaz, puede estar bastante seguro de que no habrá roto nada más arriba. Obviamente, esto aún necesitaría verificar con las pruebas.

3) Reutilizar. Escribir código de acceso a datos puede ser bastante repetitivo. Es aún más repetitivo cuando tiene que reescribir el código de acceso de datos para cada página que escriba. Cada vez que notas algo repetitivo en el código, las alarmas deberían sonar. La repetitividad es propensa a los errores y causa un problema de mantenimiento.

¿Estoy seguro de que ves las mismas consultas apareciendo en varias páginas diferentes? Esto se puede resolver colocando esas consultas más abajo en su capa de datos. Hacerlo ayuda a aliviar el mantenimiento; Cada vez que cambia un nombre de tabla o columna, solo necesita corregir el único lugar en su capa de datos que lo hace referencia en lugar de rastrear toda su interfaz de usuario y potencialmente perder algo.

4) Pruebas. Si desea utilizar la herramienta automatizada para realizar pruebas unitarias, necesitará todo bien separado. ¿Cómo probará su código para seleccionar todos los registros de clientes cuando este código esté disperso durante toda su interfaz? Es mucho más fácil cuando tiene una función específica SelectAllCustomers en un objeto de acceso a datos. Puede probar esto una vez aquí y asegurarse de que funcionará para cada página que lo use.

Hay más razones por las que dejaré agregar otras personas. Lo principal que debe quitar es que la separación de capas permite que una capa cambie sin dejar que el cambio se extienda a otras capas. Como la base de datos y la interfaz de usuario son áreas de una aplicación / sitio web que cambian con mayor frecuencia, es una muy buena idea mantenerlos separados y bien aislados de todo lo demás y entre ellos.

En mi punto de vista para imprimir solo una lista de elementos en una tabla de base de datos, su fragmento es el más apropiado: rápido, simple y claro.

pienso un poquito Más abstracción podría ser útil en otros casos para evitar repeticiones en el código con todas las ventajas relacionadas.

Considere un CMS simple con autores, artículos, etiquetas y una tabla de referencia cruzada para artículos y etiquetas.

En su página de inicio, su consulta simple se convertirá en una más compleja. Se unirá a artículos y usuarios, luego obtendrá una etiqueta relacionada para cada artículo que une la tabla de etiquetas con la referencia cruzada y filtrado por Artículo_ID.

Repetirá esta consulta con algunos pequeños cambios en el perfil del autor y en los resultados de búsqueda de etiquetas.

Usando una herramienta de abstracción como esto, puede definir sus relaciones una vez y usar una sintaxis más concisa como:

// Home page
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name');
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

Puede reducir la repetición del código restante que lo encapsula en modelos y refactorizando el código anterior:

// Home page
$articles = Author::getArticles();
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = Author::getArticles()->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = Author::getArticles()
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

Hay otras buenas razones para abstraer más o menos, con sus pros y contras. Pero en mi opinión, por una gran parte, los proyectos web lo principal es este: P

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top