Sfondo
Questa domanda nasce da una discussione architettonica che avevamo al lavoro.
Per il progetto corrente stiamo usando Python e un database orientato agli oggetti. Esistono servizi di input che consumiamo e determinate interfacce che ci aspettiamo forniscano l'output.
Qualcuno del nostro team ha iniziato a progettare un modello di dati e la mia domanda era: perché?
Un oggetto solo per dati in Python può anche essere rappresentato da un dict (ci sono molte domande su questo sito). Non disponiamo di un database relazionale con colonne che devono essere mappate su entrambi gli oggetti. Allo stesso tempo, c'è un costo per un modello di dati in quanto dovrà sempre essere mantenuto. Quando le interfacce cambiano (IMHO) diventa semplicemente un'altra dipendenza che deve essere soddisfatta, ma a differenza dei linguaggi tipizzati staticamente non impone nulla.
Domanda:
Il modo in cui mi sembra che quando ci si trova in un ambiente in cui tutto sia dinamico, è logico che le interfacce definiscano implicitamente il proprio modello di dati piuttosto che mantenere una sorta di classi che definiscono un modello. Ci sono mai buone ragioni per il contrario?
Modifica
Nei commenti e nelle risposte le persone sembrano concentrarsi su due aree: la mappatura e la rappresentazione del database e la convalida del modello di dati.
Mi scuso per non essere più esplicito riguardo al DB, ma in questo ambiente che abbiamo di fronte abbiamo un DB orientato agli oggetti che memorizza i BLOB in una rappresentazione tipo file system. Non esiste alcuna mappatura per SQL e nessun ORM di alcun genere di cui parlare. Però capisco l'argomento. Ad esempio, i modelli di Django richiedono una sottoclasse per far funzionare ORM. In questo caso, rendere le classi modello ha perfettamente senso perché il DB è effettivamente un archivio dati tipizzato statico e non "dinamico". Ma questo non è lo scenario della domanda, perché non è un puro ambiente tipizzato dinamicamente.
Per quanto riguarda i validatori: sì. Uno dovrà creare validatori che controllino i campi presenti e che siano del tipo giusto. Nei linguaggi tipizzati staticamente il modello lo fa implicitamente (quando state codificando C ++ / Java non potete attaccare l'utente 'std :: string' a dove dovrebbe essere una classe User). Ma in Python, una classe modello non impone nulla. Se sto costruendo validatori che controllano comunque la presenza di attributi, questo non rende le classi, i dettati, i generatori, ecc. Funzionalmente intercambiabili? E se sì, la soluzione non dovrebbe essere uno con meno codice? I validatori in generale mi sembrano un argomento a favore di non costruire classi di modelli di dati piuttosto che il contrario. Mi sbaglio in questo?