2009-10-24 6 views
2

J'ai une certaine structure de classe dans mon application, qui utilise actuellement django pour la présentation. Je n'utilisais pas la couche du modèle, - les routines d'interaction de la base de données sont manuscrites. Cependant, je considère la possibilité d'utiliser réellement django à son plein potentiel et d'utiliser réellement la couche d'abstraction de base de données. La question est de savoir comment intégrer au mieux ma structure de classe existante avec la couche modèle.Mappage d'objets python complexes à des modèles django

Classe exemple:

class UpperClass(base): 
    def __init__(self, attr1, attr2): 
     self.attr1 = attr1 
     self.attr2 = attr2 
     # attr1 and attr2 are actually instances of, say, 
     # CustomType1 and CustomType2 

Sow voici comment vais-je la carte à un modèle django:

class UpperClass(models.Model): 
    attr1 = CustomType1Field(...) 
    attr2 = CustomType2Field(...) 

C'est assez simple - tous les trucs sérialisation et la validation est déjà écrit , il ne sera donc pas difficile d'évoquer les classes de champs personnalisées pour CustomType1 et CustomType2. La vraie question est, où dois-je mettre le comportement personnalisé (non-base de données) de la UpperClass réelle. À ma connaissance, les modèles sont là pour «faire entrer et sortir de la base de données», mais où va le comportement? Est-ce que j'intègre les méthodes non liées à la base de données dans les instances Model de UpperClass? Vraiment, je suis perdu ici. J'espère que cela vous donne un sens au moins partiel.

Répondre

2

Cela dépend quelque peu du comportement spécifique que vous voulez coder. Dans la plupart des cas, vous devriez essayer de mettre le comportement par objet dans la classe du modèle. C'est une classe Python régulière, après tout, donc vous pouvez lui donner toutes les méthodes que vous désirez. Vous devez tenir compte de la nature persistante, bien sûr, par ex. en évitant les données de membre supplémentaires au-delà de celles spécifiées dans le schéma.

+0

Soudain, cela me semble parfaitement logique. Puisque les champs de modèle (sous-classes de models.Field) retournent à python types/classes (à to_python()), peu importe comment les instances de classe de UpperClass sont initialisées, - soit par l'appel direct à __init__ de mon code (a = UpperClass (attr1 = foo, attr2 = bar)) ou via l'ORM (a = Upperclass.objects.get (...)). De toute façon, l'espace de noms d'instance est rempli avec attr1 et attr2 initialisés au type correct. Est-ce que je vous ai bien compris? – shylent

+0

Oui: les instances de UpperClass sont des objets Python réguliers, avec les attributs réguliers attr1 et attr2 (lus dans la base de données). –

+0

Merci beaucoup pour votre aide. – shylent

0

Il s'agit en grande partie d'une question philosophique concernant MVC et comment vous choisissez de l'implémenter. On peut argumenter qu'il n'y a pas de bonne manière ici, mais en supposant que vous vouliez que les objets modèles se comportent tous d'une certaine manière, indépendamment de la vue qui interagit avec eux, il est logique d'attacher ce comportement au modèle. Si le comportement est spécifique à une certaine vue et si de nombreuses autres vues interagissent avec le modèle, il peut être plus judicieux de l'associer à la vue.

Questions connexes