Modelli Django parametrizzati

0

In linea di principio, una singola applicazione Django può essere riutilizzata in due o più progetti, fornendo funzionalità pertinenti per entrambi. Ciò implica che la stessa struttura di database (tabelle e relazioni) verrà ricreata identicamente in diversi database, e la maggior parte delle volte questo non è un problema (supponendo che i progetti / database non siano collegati - ad esempio quando qualcuno scarica un'app completa da utilizzare in i propri progetti).

A volte, tuttavia, i modelli devono essere "ottimizzati" un po 'per adattarsi meglio alle esigenze del problema. Questo può essere ottenuto biforcando l'app, ma mi chiedevo se non ci sarebbe stata un'opzione migliore nei casi in cui il progettista dell'app potesse anticipare le personalizzazioni più comuni.

Ad esempio, se ho un modello che potrebbe riguardare un altro come uno-a-uno o uno-a-molti, potrei specificare la proprietà unique come parametro, che può essere specificata nelle impostazioni del progetto:

class This(models.Model):
    other = models.ForeignKey(Other, unique=settings.OTHER_TO_THIS)

O se un modello può riguardare molti altri, potrei creare una tabella intermedia per ognuno di essi (rafforzando così l'integrità referenziale) invece di usare fks generici:

for related in settings.MODELS_RELATED_TO_OTHER:
    model_name = '%s_Other' % related
    globals()[model_name] = type(model_name, (models.Model,) {
        me:models.ForeignKey(find_model_class(related)),
        other:models.ForeignKey(Other),
        # Some other properties all intersection tables must have
    })

Ecc. Permettetemi di sottolineare che sono non proponendo di cambiare i modelli in fase di runtime e nulla del genere; una volta definiti i parametri e chiamato syncdb per la prima volta, questi parametri non devono essere modificati di nuovo (a meno che non si stia eseguendo una migrazione dello schema).

È un buon design? Ci sono modi migliori per realizzare la stessa cosa, o forse degli inconvenienti che non posso anticipare? Questa tecnica è pensata per essere usata con parsimonia (solo su app pensate per essere riutilizzate in contesti selvaggi e solo quando è possibile rilevare una specifica esigenza di personalizzazione durante la progettazione del modello di app).

    
posta mgibsonbr 24.05.2012 - 22:31
fonte

1 risposta

1

Penso che i modelli dovrebbero essere astratti e gli utenti della biblioteca dovrebbero estenderli in classi concrete che si riferiscono alle loro classi specifiche.

Se alcune relazioni devono avere cardinalità diversa, è possibile gestirle utilizzando l'ereditarietà del modello: avere una classe base che non definisce la relazione e che ha metodi di template per il codice coinvolto nella relazione e sottoclassi che definiscono la cardinalità e implementare i metodi del modello. A meno che tu non abbia molte varianti diverse all'interno della stessa classe (che non mi sembra una cosa comune per me), dovrebbe funzionare.

Se ciò non soddisfa i tuoi requisiti, sì, potresti dover costruire i tuoi modelli in modo programmatico, suoni fattibili ma complessi.

Come commento finale, stai lontano dalle chiavi esterne generiche. Potrebbero funzionare un po 'se non esci da Django, ma ...

    
risposta data 27.06.2012 - 21:30
fonte

Leggi altre domande sui tag