El código primero: Los peligros del enfoque "Code First

El marco de mapeo objeto-relacional (ORM) ofrece un enfoque de código primero como opción viable para modelar estructuras de datos. Al reducir un paso en el desarrollo de una aplicación empresarial, el marco code first promete una forma eficiente de crear software sin muchas complicaciones.

Pero tiene sus ventajas y sus inconvenientes. En este blog, nuestro equipo destaca algunos de los peligros del enfoque code-first.

Entendamos primero el tema que nos ocupa.

¿Qué es Code First?

Tradicionalmente, cuando se crea una aplicación, especialmente una aplicación empresarial, se tiene en cuenta la estructura de datos. Desarrollarías una base de datos con la ayuda de un equipo con diferentes habilidades que, juntos, construyen el código, que más tarde se comprueba y ejecuta. Nosotros utilizamos dos formas distintas de conceptualizar los entornos que intentamos formalizar con software.

Así que aquí tenemos dos mundos implicados en todo el proceso de creación de una aplicación:

• Modelo relacional: Es un marco para describir un dominio. Trabaja con la estructura de la base de datos, su código y los datos en reposo.

• Modelo de Objetos: El segundo realiza el código de la aplicación. Consiste en la representación visual de la aplicación.

Debemos comprobar el mantenimiento de estos dos mundos juntos, pero por separado. Ambos modelos tienen sus puntos fuertes y débiles a la hora de concebir cualquier dominio. Antiguamente, cuando los desarrolladores solían trabajar en proyectos que requerían estos dos paisajes para la modelización, daba lugar a lo que los informáticos llaman impedance mismatch (problemas que se producen debido a la incoherencia entre la base de datos y el modelo de programación). Todo esto puede acarrear muchos problemas.

Aunque la aplicación se construya con un desajuste de impedancias mínimo, surgirán problemas cuando llegue el momento de modificarla.

Entonces aparecieron los wireframes, que facilitaban a los desarrolladores el acceso a la base de datos desde el código sin conocer la base de datos. Estos marcos siguieron evolucionando y ahora el código podía traducirse a la estructura de la base de datos.

Mantener dos mundos separados para la base de datos y el código de la aplicación pronto desapareció con este descubrimiento. Los wireframes se ocupaban de la base de datos ocupándose del código. Ahora sólo hay que trabajar en un único mundo, y eso es lo que se llama una idea atractiva.

La metodología code first partió de esta idea y aprovechó la evolución tecnológica. Actúa como un mazo, haciendo que los diferentes dominios de modelado sean opacos para el desarrollador de software. Así, en lugar de tener dos entornos de trabajo separados, los desarrolladores sólo tienen que trabajar en un entorno de modelado de objetos (OME).

En palabras sencillas, si utilizas un marco de trabajo que prioriza el código, vas a definir el entorno empresarial utilizando un único lenguaje de modelado, que será uno de objetos. Y el código que utilices hará todo lo posible por traducir tus compromisos de modelización al espacio relacional o al espacio que estés utilizando.

Al desaparecer la necesidad de contar con dos equipos distintos para crear una aplicación, el lema pasó a ser “simplemente empieza a codificar”. Construye tus objetos y repositorios de bases de datos que contengan esos objetos, persiste en esos objetos, y todo cobrará existencia por arte de magia.

Comprensión a través de un ejemplo de cómo funciona el modelo Code-First

Digamos que un editor viene a un desarrollador donde necesitan un nuevo sistema para el seguimiento de libros y autores. La forma antigua de construir el sistema sería conseguir un analista de negocios (BA) en el proyecto y crear un modelo de información canónica de los libros y autores. Después, este modelo canónico se comparte con los arquitectos de bases de datos y aplicaciones. A continuación, ambos desarrolladores recapitularán ese modelo en términos que puedan utilizarse para construir una base de datos y en términos que se utilicen para construir la capa de aplicación. Por tanto, tanto los arquitectos de bases de datos como los de aplicaciones hablan de lo mismo, pero uno trabaja en dot net y el otro en SQL.

El código primero dice que el BA sigue desarrollando el modelo canónico, pero lo comparte con un solo arquitecto. Ese único desarrollador recapitulará el modelo en un entorno de objetos. Y luego, un marco de trabajo de “primero el código” construirá el modelo de objetos en un lenguaje que la base de datos persistente, a menudo una base de datos relacional o de objetos, pueda entender.

Los peligros del código primero

Los frameworks de código primero a menudo se utilizan en proyectos más pequeños, y a veces las empresas los extienden a proyectos a gran escala, lo cual es peligroso. Pero lo que ocurre en los proyectos más pequeños es que los propietarios de las empresas a menudo ponen directamente a un desarrollador a trabajar en el proyecto sin ningún análisis previo por parte de un BA.

Como el proyecto es a menor escala, el desarrollador se mete de cabeza en él y empieza a codificar. El desarrollador construye los objetos que representan las necesidades de la aplicación.

En medio, el desarrollador y el propietario de la empresa olvidan que la aplicación es un modelo del mundo real. La transición de un mundo real a uno virtual la realiza mejor alguien altamente cualificado. Un desarrollador y un arquitecto no lo consiguen, ya que se forman en la fundamentación de un modelo en el espacio digital. Por otro lado, un analista sabe cómo alterar un modelo del mundo real para el espacio digital y aporta ese modelo a los desarrolladores. Por lo tanto, uno de los principales riesgos de utilizar primero el código es ignorar el análisis empresarial y precipitarse hacia el desarrollador.

El segundo peligro es el rendimiento del sistema. Por ello, el marco de trabajo “code-first” a menudo implica que haya un mapeador objeto-relacional (ORM) en la mezcla. El code-first ofrece al desarrollador la posibilidad de trabajar en un único entorno de modelización, el OME. Significa que dependemos de un software con visión de futuro para escribir las consultas.

En DOOR3, hemos ayudado a muchos clientes que ya se han embarcado en un proyecto de aplicación code-first, han construido algo, lo han aceptado en producción, y luego sólo para verlo detenerse. Al inspeccionarlo, hemos visto que el SQL estaba escrito de una forma tan poco óptima por la arquitectura code-first o el ORM que hemos tenido que entrar y sustituirlo por código escrito a mano. Así pues, el rendimiento es otro elemento que debemos vigilar cuando trabajamos con code-first.

Todo esto también puede llevar a la mantenibilidad del rendimiento. Aunque el código primero es más fácil de trabajar, una cosa que frustra a muchos desarrolladores es que no hay ninguna herramienta presente en el ORE en términos de ajuste de la aplicación. Todo se hace a través de ORE en la aplicación. En el momento en que empiezas a hacer cambios unilateralmente a nivel de almacenamiento, puedes romper el ORE o limitar el ORE de esa sección de cambios.

Conclusión

Así que, aquí hemos discutido en qué consiste el enfoque de “primero el código” y cuáles son algunos peligros ocultos detrás de él. A pesar de que el modelo tiene algunos problemas de eficiencia, todavía funciona muy bien para la construcción de aplicaciones a pequeña escala y para impulsar el crecimiento. Si desea saber más sobre nuestros servicios, póngase en contacto con nosotros.