ORM Classes e Separation of Preoccupations

2

Sto usando l'ORM peewee di Python per mappare il mio database relazionale, ma sto notando che i miei modelli stanno cominciando a gonfiarsi e sembra anche che stia violando la separazione dei dubbi.

Ad esempio, la mia classe User ha metodi auto esplicativi come

authenticate()
push_message()
upload_image()

Anche se è utile chiamare user.authenticate() o user.upload_image() , questi metodi implicano l'utilizzo di molti pacchetti e / o API di terze parti e mi chiedo se sarebbe meglio separarli dal modello.

Un modo in cui posso pensare di sistemarlo è spostare tutti questi metodi in un altro livello (e separare ulteriormente quel livello per i vari domini) e usarli in questo modo:

authenticate_user( user )
push_user_message( user )
upload_user_image( user )

Ma ciò sembra in contraddizione con l'utilità di OOP. Un altro modo è forse quello di combinare la mia idea originale e usare un'interfaccia di sorta?

class UserAuthentication( object )
    # authentication code goes here

# These would be in separate packages and/or modules
class User( model ):
    def authenticate( self ):
        return UserAuthentication( self ).authenticate()

Ma questo potrebbe introdurre complessità estemporanea.

    
posta Jacob Hull 07.07.2017 - 05:32
fonte

1 risposta

5

Penso che potresti confondere un dominio / modello di business con una classe di servizio. Un modello rappresenta più o meno un oggetto e un comportamento reali, in cui una classe di servizio avvolge il modello ed esegue azioni contro di esso che non sono necessariamente parte del modello stesso.

Ad esempio, un utente potrebbe avere una proprietà Image, ma UploadImage è un'azione che non è specifica del modello stesso, ma specifica di come implementare il recupero di un'immagine nel modello .

Gli ORM possono avvolgere il livello del modello e fornire la mappatura della persistenza (usando un'API Fluent, puoi farlo senza inquinare il tuo livello del modello (almeno questo è quello che faccio in .NET - non molto esperto in Python)). Il tuo servizio farebbe uso della persistenza, ma il modello di base stesso (quello che rappresenta il tuo utente, o cliente, o ordine, ecc.) Non conosce altro che i propri metodi ed eventi di proprietà.

Il livello di servizio, tuttavia (che potrebbe implementare un metodo AttachImage() ), utilizzerebbe sia il modello che il livello di persistenza insieme per eseguire l'attività richiesta.

In questo modo il tuo modello è pulito, il tuo ORM è pulito (basandosi solo sul modello) e le tue classi di servizio possono essere progettate per fare solo ciò che devono fare e la tua applicazione interagisce più o meno con i servizi.

(nota che non c'è una piccola quantità di ambiguità su cosa sia un "modello" - lo uso qui in termini di un modello di dominio, un oggetto del livello aziendale che rappresenta un'entità aziendale ... allo stesso modo, ho offuscato il allinea un po 'tra il livello di servizio e quello dell'applicazione, in modo da non creare troppi problemi nella mia risposta ...)

    
risposta data 07.07.2017 - 16:47
fonte

Leggi altre domande sui tag