¿Por qué construir modelos de datos en un lenguaje dinámico?

7

Background

Esta pregunta surge de una discusión arquitectónica que tuvimos en el trabajo.

Para el proyecto actual, estamos usando Python y una base de datos orientada a objetos. Hay servicios de entrada que consumimos y ciertas interfaces que se espera que proporcionemos salida a través.

Alguien en nuestro equipo comenzó a diseñar un modelo de datos, y mi pregunta fue: ¿por qué?

Un objeto de solo datos en Python también puede ser representado por un dict (hay una gran cantidad de preguntas sobre eso en este sitio). No tenemos una base de datos relacional que tenga columnas a las que necesitamos asignar los objetos. Al mismo tiempo, hay un costo para un modelo de datos en el sentido de que siempre será necesario mantenerlo. Cuando las interfaces lo cambian (IMHO) simplemente se convierte en otra dependencia que debe satisfacerse, pero a diferencia de los lenguajes de tipo estático, en realidad no impone nada.

Pregunta :

La forma en que me parece es que cuando estás en un entorno donde todo es dinámico, tiene sentido que las interfaces definan tu modelo de datos implícitamente en lugar de mantener algún tipo de clases que definan un modelo. ¿Hay alguna buena razón para lo contrario?

EDIT

En los comentarios y respuestas, parece que las personas se centran en dos áreas, que son: mapeo y representación de la base de datos, así como la validación del modelo de datos.

Pido disculpas por no ser más explícito sobre la base de datos, pero en este entorno al que nos enfrentamos, tenemos una base de datos orientada a objetos que almacena blobs en una representación similar a un sistema de archivos. No hay asignación a SQL ni ORM de ningún tipo para hablar. Aunque entiendo el argumento. Por ejemplo, los modelos de Django requieren subclases para que ORM funcione. En este caso, crear clases de modelo tiene mucho sentido porque el DB es efectivamente un almacén de datos de tipo estático y no "dinámico". Pero este no es el escenario de la pregunta, porque no es un entorno de tipo dinámico puro.

Respecto a los validadores: sí. Uno tendrá que crear validadores que verifiquen que los campos estén presentes, y que sean del tipo correcto. En los lenguajes de tipo estático, el modelo hace esto de manera implícita (cuando está codificando C ++ / Java, no puede pegar el usuario 'std :: string' a donde debe estar una clase de Usuario). Pero en Python, una clase modelo no impone nada. Si estoy construyendo validadores que verifican la presencia de atributos de todos modos, ¿esto no hace que las clases, los dicts, los generadores, etc. sean funcionalmente intercambiables? Y si es así, ¿no debería ser la solución una con menos código? Los validadores en general me parecen un argumento a favor de no construir clases de modelos de datos en lugar de lo contrario. ¿Estoy equivocado en esto?

    
pregunta MrFox 28.02.2013 - 20:50

2 respuestas

6

Incluso en un lenguaje dinámico, los principios de Diseño impulsado por dominio aún pueden aplicarse. Si todo lo que está haciendo es pasar los diccionarios, tiene un modelo anémico donde sus objetos son datos puros y otros objetos operan en ellos.

Tomarse el tiempo para crear un modelo de objeto enriquecido e integrar la lógica en el modelo brinda una oportunidad para que su modelo sea más expresivo y representativo del dominio que está modelando.

    
respondido por el Michael Brown 28.02.2013 - 21:58
2

Cuando trabajé contra Mongo recuperamos los diccionarios. En algunas partes del código lo convertimos en un objeto real. En otros lugares lo guardamos un diccionario. En la mayoría de los casos, los objetos fueron solo por conveniencia, por lo que podríamos decir customer.name en lugar de customer["name"] . En estos casos, utilizamos un diccionario de puntos (una clase que reemplaza a __getattr__ ).

Hubo casos en que el modelo de dominio "vio" los datos de manera diferente. En estos casos, creamos objetos con la estructura que queríamos y asignamos nuestros objetos de datos a ellos. Puede hacer una gran diferencia en la facilidad de lectura para hacer este mapeo una vez al principio en lugar de dispersarse en todo su código.

Otro lugar donde un objeto real fue útil fue cuando validó el esquema. Hay algunos envoltorios Mongo que le permitirán definir cheques al agarrar y almacenar documentos. Esto es útil para mantener su "esquema" coherente ante el error del usuario. Pueden proporcionar valores predeterminados para los atributos que faltan, convertir fechas en cadenas y cosas de esa naturaleza. Existen bibliotecas similares para trabajar con JSON devueltas desde una aplicación web.

    
respondido por el Travis Parks 28.02.2013 - 21:35

Lea otras preguntas en las etiquetas