¿Cómo evitar la duplicación de estructuras de datos cuando las partes de una aplicación están escritas en diferentes idiomas?

12

Como ejemplo, supongamos que está escribiendo una aplicación en Java .

Su aplicación se comunica con un servidor API escrito en Python .

El servidor Python se comunica con una base de datos SQL .

También tiene un sitio web para su aplicación escrito en JavaScript .

Con 4 idiomas diferentes, es fácil terminar repitiendo esencialmente las mismas estructuras de datos 4 veces diferentes.

Por ejemplo, un tipo User podría tener este aspecto (pseudocódigo):

type User {
  integer id;
  string name;
  timestamp birthday;
}

Cada parte del proyecto necesitaría algún tipo de representación para User . Las partes de Java y Python necesitarían dos declaraciones class diferentes. La base de datos necesitaría una declaración de tabla User . Y el sitio de front-end también tendría que representar un User .

La repetición de este tipo 4 veces diferentes realmente rompe el principio de No repitirse . También existe el problema de que si se modifica el tipo User , estos cambios deben repetirse en cada parte diferente del proyecto.

Sé que la biblioteca protobuf de Google ofrece un tipo de solución a este problema en el que escribe una estructura de datos con una sintaxis especial, y entonces la biblioteca genera una declaración de estructura para usted en múltiples lenguajes de programación diferentes. Pero esto todavía no trata el problema de tener que repetir la lógica de validación para sus tipos.

¿Alguien tiene alguna sugerencia o enlace a libros / publicaciones de blog sobre esto?

    
pregunta Normangorman 09.02.2018 - 02:18

2 respuestas

12

No lo haces. O realmente, no deberías.

Si piensa que la aplicación, su servidor y su sitio web son contextos separados, entonces tiene sentido que haya estructuras duplicadas. Razones por las que podría ser una buena cosa:

  • Las estructuras son similares, pero no iguales. Incluso si el 90% de la estructura es la misma en todos los contextos. Es el 10% que te dará dolores de cabeza masivos.
  • Los patrones y las implementaciones pueden ser diferentes. Cuando se usan diferentes lenguajes y marcos, se vuelve demasiado difícil tener la misma implementación en todos ellos
  • Las estructuras compartidas se convierten en una dependencia que debe gestionarse. Tener una dependencia compartida complica enormemente el desarrollo, ya que el cambio que es grande en un contexto es abismal en otro. Por lo tanto, se necesita mucho esfuerzo para coordinar el desarrollo de esta dependencia compartida
  • Los diferentes contextos tienen diferentes implementaciones. Incluso si logra compartir las mismas estructuras de datos y el mismo código de validación en todos los contextos, todavía puede ocurrir que se implemente una nueva versión de un contexto mientras que otros están en una versión antigua, por lo que aún es necesario desincronizar las versiones. ser abordado

Si bien el principio DRY es sorprendente, creo que compartir estructuras de datos en contextos o capas crea más problemas de los que resuelve. Especialmente si el proyecto crece lo suficiente como para que diferentes personas trabajen en diferentes contextos.

    
respondido por el Euphoric 09.02.2018 - 06:25
5

Creo que @Euphoric enumeró un par de buenas razones para no duplicar su código. Sin embargo, si debe hacerlo, le recomendaría que utilice la generación de código.

Encuentre la forma canónica de los datos

Para hacerlo con eficacia, primero debe descubrir cuál es la forma canónica de los datos. ¿Es su esquema SQL, o clases en su programa Java?

Derive (automáticamente) las otras formas de ella

Después de eso, diseña una manera de generar todas las otras formas a partir de la canónica. Por ejemplo, asumiendo que su forma canónica es el esquema de SQL, puede generar código JavaScript, Java y Python a partir de eso fácilmente (SQL se analiza fácilmente y es un buen candidato para la fuente canónica).

Acomodar las diferencias

Debería ser fácil marcar las secciones del código generado como "no tocar", de esta manera acomodaría las diferencias requeridas entre todas las diferentes representaciones (por ejemplo, el código personalizado que escribió para su interfaz JS y Java). backend) que deben conservarse en las regeneraciones.
Tomemos un ejemplo de Git; cuando abre un editor para permitirle ingresar un mensaje de confirmación, el archivo ya contiene algo de texto, pero tiene el marcador # -------- >8 -------- para saber dónde termina su contenido, y dónde es el texto generado automáticamente comienza.

Aún así, si puede, evite dicha duplicación. Es un PITA, incluso si la mayoría de su código se genera automáticamente.

Esta respuesta es un poco como un cuento en lugar de "aquí hay algunas de las mejores prácticas". Lo que describí es exactamente lo que una vez hice cuando tuve el mismo problema que usted y necesitaba tener los mismos datos representados en diferentes partes del sistema (o, más bien, en dos sistemas diferentes).

    
respondido por el Mael 09.02.2018 - 08:28

Lea otras preguntas en las etiquetas