Oggi ho avuto un acceso dibattito con un altro sviluppatore della mia organizzazione su dove e come aggiungere metodi alle classi mappate al database. Utilizziamo sqlalchemy , e una parte importante della base di codice esistente nei nostri modelli di database è poco più di un sacco di proprietà mappate con un nome di classe, una traduzione quasi meccanica dalle tabelle del database agli oggetti python.
Nell'argomento, la mia posizione era che il valore primario dell'uso di un ORM era che è possibile associare comportamenti e algoritmi di basso livello alle classi mappate. I modelli sono prima le classi e secondariamente persistenti (potrebbero essere persistenti usando xml in un filesystem, non è necessario preoccuparsene). Il suo punto di vista era che qualsiasi comportamento fosse "business logic", e necessariamente appartiene a qualsiasi parte tranne che nel modello persistente, che deve essere usato solo per la persistenza del database.
Certamente penso che ci sia una distinzione tra ciò che è la logica aziendale, e dovrebbe essere separato, poiché ha un certo isolamento dal livello inferiore di come viene implementato, e la logica del dominio, che Credo che l'astrazione fornita dalle classi modello sia discussa nel paragrafo precedente, ma sto facendo fatica a mettere il dito su quello che è. Ho un'idea migliore di ciò che potrebbe essere l'API (che, nel nostro caso, è HTTP "ReSTful"), in quanto gli utenti invocano l'API con ciò che vogliono fare , distinti da ciò che sono permesso di fare e come si fa.
tl; dr: Quali tipi di cose possono o dovrebbero andare in un metodo in una classe mappata quando si usa un ORM e cosa dovrebbe essere lasciato fuori, per vivere in un altro livello di astrazione?