Las tecnologías de la información modernas sorprenden con su poder, están abrumadas por las oportunidades que se abren, se desaniman por la perfección técnica inherente a ellas, pero hay un punto ridículo sobre el cual TI rompe sus dientes una y otra vez. Muestre los datos de usuario de la base de datos, obtenga información de él, vuelva a colocarlos en la base de datos, muestre el resultado. Campos de entrada, botones, marcas de verificación, inscripciones: parece que pueden ser tan prohibitivamente difíciles de exigir construcciones desconcertantes como marcos en la parte superior de los motores de plantillas en la parte superior de los marcos en la parte superior de los transpiladores. Y por qué, a pesar de todos los enormes esfuerzos, tenemos el hecho de que los ejemplos de juguetes en el tutorial, por supuesto, se hacen fácil y agradablemente, pero tan pronto como el juego de herramientas encuentra las tareas reales de la vida real ... cómo decirlo más suave ... con una complejidad cada vez mayor de las tareas a resolver, hay una fuerte no linealidad de aumento dificultades de implementación Bueno, sería una cuestión de algo realmente desconcertante a nivel de física teórica o tecnología espacial, porque de todos modos no hay botones ni marcas de verificación. ¿Por qué este sinsentido continúa envenenando la vida de los ciudadanos y los colectivos de trabajo durante décadas?
Las razones, probablemente, como siempre, son muchas. Probablemente todos ellos sean dignos de consideración de una manera u otra, pero aquí y ahora hablaremos sobre la tarea de Mapeo de objetos relacionales (ORM), que siempre está detrás de algunos de estos "botones y marcas de verificación" de alguna forma.
¿Qué sabemos sobre ORM?
- Almacenar datos en tablas relacionales no significa que sea una cuestión muy simple, pero en general, tanto la idea como las formas de su aplicación son bastante claras y están bien investigadas.
- Con la programación de objetos, no todo es tan bueno (hay varios enfoques competitivos), pero en general, con la implementación y aplicación de tecnologías, todo también está más o menos claro.
- Tanto eso como otro, sobre los datos, su almacenamiento y procesamiento. Eso es, de hecho, casi lo mismo.
- Nos parece lógico que haya un puente simple, comprensible, conveniente, predecible y universal entre los dos mundos.
- Y cada vez que encontramos este puente fácilmente, pero la desgracia, su simplicidad, comprensibilidad, conveniencia, previsibilidad y universalidad no funcionan más allá de simples ejemplos de tutoriales.
- Todos sufren: los desarrolladores, que tienen que hacer un trabajo extremadamente aburrido, y los usuarios que tienen que luchar con un software torpe, y el negocio, cuya realización de repente resulta ser insoportablemente larga y costosa, y la industria en general.
- He visto muchos ORM diferentes, pero no he visto ninguno bueno. Es decir, uno que, más allá de los simples ejemplos, no se convierte en una carga y una cama Procrustean.
¿Por qué todo es tan extraño?
La base ideológica de la teoría y la práctica de las bases de datos relacionales es el cálculo de predicados, es decir, una rama de las matemáticas. En cuanto a la POO, falta una base ideológica similar allí. Uno puede tratar de formular la idea básica de OOP de esta manera: dado que el mundo consiste en objetos, sería conveniente modelarlo, este mundo, creando objetos dentro de un sistema de software. En este sentido, dos errores a la vez. En primer lugar, el mundo mismo no consiste y nunca consistió en objetos. En segundo lugar, lo siento, pero ¿por qué el programa tiene que simular el mundo? Es decir, tenemos una declaración conceptualmente incorrecta, perfectamente complementada por una declaración sin sentido del problema.
Cada ORM es un intento de estirar claramente la correspondencia unificada entre, de hecho, la rama de las matemáticas y un conjunto amplio de prácticas diversas, basadas en consideraciones de conveniencia, enfoques históricamente establecidos, y también a menudo en leyendas, opiniones de autoridades y simplemente conceptos erróneos. In vitro se puede hacer que funcione, pero in vivo está condenado a parecer patético y traer más dolor que alegría.
Sobre la inevitabilidad de la orientación a objetos.
Sin embargo, la necesidad de la orientación a objetos de nuestro software es nuestra realidad inevitable. Esta inevitabilidad se basa principalmente en el hecho de que operar con objetos es la esencia y el fundamento de cualquiera de nuestras actividades. El mundo en sí no consiste en objetos, pero para comprender algo en este mundo y hacer algo con este mundo, nosotros mismos declaramos sus partes como objetos, los llamamos nombres, tratamos de entender su comportamiento, aplicamos a Los esfuerzos para obtener los resultados deseados. Esta es nuestra forma de funcionamiento, y es imposible dejarlo, y no es necesario. Todo es un objeto, no porque realmente lo sea, sino porque no podemos hacer otra cosa. Lo que de ninguna manera puede ser un objeto está completamente fuera de los límites de nuestra capacidad de comprender y no puede servir como sujeto de nuestros esfuerzos.
Incluso si el programa se escribe sin el uso de técnicas OOP, inevitablemente contiene objetos (en el sentido amplio de la palabra), al manipular qué desarrollador resuelve su problema: variables, tipos de datos, operadores, algoritmos, construcciones sintácticas, funciones, módulos. Desde el punto de vista del usuario, el programa también tiene un conjunto de objetos con los que interactúa: botones, etiquetas, campos de entrada, páginas, sitios y todo el sistema.
Lo que almacenamos en nuestras bases de datos
Como se mencionó anteriormente, las bases de datos relacionales se basan en el cálculo de predicados. Un predicado es un hecho formulado y, en nuestro caso, almacenado en un medio. Por si acaso, noto que la base de datos relacional no es solo y no tanto sobre las relaciones entre tablas mediante claves externas. En la terminología adecuada, las relaciones son lo que simplemente llamamos tablas. Es decir, incluso si su base de datos tiene solo una tabla con dos columnas (por ejemplo, nombre y número de teléfono), ya tiene una base de datos relacional que establece la relación entre dos conjuntos, en este caso, conjuntos de nombres y números de teléfono.
Una base de datos relacional no almacena objetos; almacena hechos. Los hechos almacenados, por supuesto, tienen un objeto ("¿de qué se trata este hecho?"), Y cuando tratamos de enseñar al sistema a responder a esta pregunta, tenemos entidades, es decir, objetos con los cuales los hechos están asociados. Si trabaja correctamente, la estructura de nuestra base nace de una serie de respuestas a la pregunta "¿qué tipo de hechos pretendemos mantener?", Y solo en la siguiente etapa obtenemos algo que se asemeja a objetos que dan hechos a la objetividad. Por supuesto, puede diseñar "a partir de objetos", pero no recomendaría hacerlo, excepto en el trabajo de laboratorio en temas que no están directamente relacionados con el diseño de la base de datos. El peligro de grandes errores de cálculo arquitectónicos es demasiado grande. Además, es al menos inconveniente.
Una pequeña digresión sobre las bases de datos de objetos. Una idea muy simple: si estamos cansados de problemas con ORM, ¿entonces quizás deberíamos hacer algo con la parte que es "R"? Deje que nuestra base de datos no sea un monstruo relacional duro y exigente, sino algo juvenil de moda especialmente diseñado para almacenar objetos. Algún tipo de esquema NoSQL-base, por ejemplo. Pero al final, de repente resulta que los ORM similares a NoSQL son aún más incómodos y antinaturales que los viejos y buenos SQL. De todos modos, podemos tener y con mucho gusto operar un DBMS sin circuito, pero no hay datos libres de circuito en la naturaleza. No hay nada más indefenso, irresponsable e inmoral que ORM para bases de datos sin circuito.
Buena ORM
Un buen ORM es el ORM que falta. Pues en serio. Mire cualquiera de sus sistemas ORM y honestamente intente responder a su pregunta: ¿cuáles son los beneficios de este monstruo? ¿Cuál es la razón de su uso, excepto las promesas de felicidad incumplidas y las desacreditadas repetidamente perjudicadas? Por supuesto, hay algunas cosas útiles útiles, pero ¿cuáles son en el contexto de las deformaciones arquitectónicas introducidas y los problemas de rendimiento que surgen constantemente de la nada?
Como regla general, la API de base de datos de "bajo nivel" es simple, conveniente, completa y consistente. Por lo general, suficientes dedos para enumerar todas las características. Aprenderlos no es una buena noticia, qué tarea.
Trataré de esbozar un conjunto de principios arquitectónicos que le permitan asignar objetos a una base de datos sin usar ORM:
- Almacenamos los hechos, operamos en objetos. Recuerde que la base de datos almacena hechos, y los modelos de objetos involucrados en el procesamiento de datos son proyecciones de conjuntos de hechos desde diferentes puntos de vista. Por ejemplo, para el ejemplo dado con nombres y números de teléfono, podemos tener la clase Abonent, para la cual se pueden almacenar varios números, y también la clase PhoneNumber, para la cual se pueden configurar varios suscriptores (no olvide que además de los números móviles personales, tenemos donde todavía hay teléfonos de departamentos y oficinas). Y la tabla en la base de datos es solo una que define la relación de muchos a muchos entre muchos nombres y números de teléfono. Solo dos proyecciones diferentes. Este enfoque, por cierto, normalmente se escala a casos mucho más complejos, lo que le permite tener clases tan útiles en el sistema como, por ejemplo, "ventas promedio para un período determinado de acuerdo con una combinación de criterios dada".
- Los hechos se proyectan en objetos y viceversa a través de una API orientada a problemas. Sin aplicar una solución que dice ser universal. Si aún no sabe cómo componer API convenientes, aprenda cómo hacerlo. Y lo más importante, enséñese a documentarlos de inmediato.
- Orden sobre todo. Si utiliza la versión clásica de un DBMS con un esquema de datos rígido, entonces este esquema en sí mismo ordena el trabajo con los datos. La estructura adicional codificada por la estructura de los objetos es simplemente redundante. Si usa un DBMS sin esquemas, entonces, por supuesto, tendrá que hacer algunos esfuerzos para asegurarse de que su base de datos no se convierta en una montaña de basura debido al hecho de que diferentes desarrolladores tienen diferentes ideas sobre lo que se almacena.
- Independencia de DBMS (si es necesario). Si la propiedad más interesante de ORM para usted es la independencia de DBMS, utilice herramientas especiales como ODBC, JDBC, ADO, o si esto no es posible, cree su propio nivel de abstracción. No es tan difícil como podría parecer al principio. No necesita soporte para absolutamente todas las capacidades de absolutamente todos los DBMS para su tarea, ¿verdad?
- No se olvide de los aspectos adicionales de trabajar con datos. Como, por ejemplo, compartir el acceso a los datos (que pueden ser arbitrariamente complejos), monitoreo, replicación y más. Pero aquí tengo buenas noticias para ti: porque en tu ORM favorito, el complemento. el aspecto aún se implementa de acuerdo con el principio "no complacerá a todos, comerá lo que da", el rechazo de un servicio dudoso con el que tiene que luchar más que cooperar demostrará en última instancia ser una decisión estratégicamente correcta.
Total
ORM es un tema muy doloroso para nuestra industria. En una era en la que la inteligencia artificial en la nube es la cadena de bloques cuántica, la gran mayoría de la fuerza laboral está ocupada entrelazando la lógica empresarial y una interfaz de usuario a las bases de datos. Millones de líneas de código terrible, clavadas con microscopios, dolor y desesperación en todas partes acompañan este proceso creativo. Una de las raíces de este triste estado de cosas es la idea errónea extremadamente persistente de que un ORM universal es en principio posible. Pero es imposible, y hay una razón fundamental para esto, que no puede eliminarse. La conciencia de este hecho es el primer paso para salir de esta pesadilla. Hay una salida, hay alternativas, pero primero debes darte cuenta, sentir y aprender a mantener el foco de atención.
PD: Pido disculpas sinceramente a esos hermanos en la profesión que han invertido mucho tiempo y esfuerzo en crear numerosos mejores universales en el mundo de ORM. Lo siento mucho