Αρχαρίων: Προσπαθώντας να κατανοήσουμε πώς οι εφαρμογές αλληλεπιδρούν σε Django

ψήφοι
28

Πήρα ακριβώς το τέλος της εργασίας μέσα από τα σεμινάρια Django για δεύτερη φορά, και είμαι κατανόηση τα πράγματα πολύ πιο καθαρά τώρα. Ωστόσο, είμαι ακόμα ασαφές το πώς οι εφαρμογές μέσα σε ένα χώρο αλληλεπιδρούν μεταξύ τους.

Για παράδειγμα, ας πούμε γράφω μια εφαρμογή ιστολογίου (μια μάλλον δημοφιλής δραστηριότητα, προφανώς). blog θέσεις και τα σχόλια τείνουν να πάνε μαζί, και όμως είναι αρκετά ότι θα πρέπει να κατασκευαστούν σε ξεχωριστές εφαρμογές διακριτά, όπως είναι η γενική φιλοσοφία της ανάπτυξης Djano.

Εξετάστε το ακόλουθο παράδειγμα. Στην πραγματικότητα δεν θα ήταν στην πραγματικότητα γράψει το σχόλιο app τον εαυτό μου, τόσο καλό κώδικα για αυτό υπάρχει ήδη στο διαδίκτυο, αλλά αυτό είναι για λόγους επίδειξης / πρακτική:

mysite / blog / models.py

from django.db import models

class post(models.Model):
    title = models.CharField(max_length=200)
    author = models.CharField(max_length=200)
    content = models.TextField()

mysite / σχόλια / models.py

from django.db import models
from mysite.blog.models import post

class comment(models.Model):
    id = models.AutoField()
    post = models.ForeignKey(post)
    author = models.CharField(max_length=200)
    text = models.TextField()

Είναι αυτό που έγραψα πιο πάνω, εισάγει ένα μοντέλο από μια άλλη εφαρμογή και να ορίσετε ως ξένο κλειδί, πώς Django εφαρμογές αλληλεπιδρούν; Ή είναι μια διαφορετική / καλύτερη μέθοδος για τις εφαρμογές που περιλαμβάνουν ένα site για να αλληλεπιδράσουν εκεί;

Ενημέρωση
Per τη σύσταση σε μια απάντηση, διαβάζω την τεκμηρίωση για contrib.contenttypes. Αν είμαι διαβάζετε αυτό σωστά, θα μπορούσε να ξαναγράψει το παράδειγμά μου σχόλιο app όπως αυτό:

from django.db import models  
from django.contrib.contenttypes.models import ContentType
from django.contrib.contentypes import generic

class comment(models.Model):  
    id = models.AutoField()  
    author = models.CharField(max_length=200)  
    text = models.TextField()  
    content_type = models.ForeignKey(ContentType)  
    content_object = generic.GenericForeignKey(content_type, id)  

Μήπως αυτό είναι σωστό;

Δημοσιεύθηκε 09/12/2008 στις 18:25
πηγή χρήστη
Σε άλλες γλώσσες...                            


4 απαντήσεις

ψήφοι
21

Ρίξτε μια ματιά σε Django ενσωματωμένο στο πλαίσιο CONTENTTYPES :

django.contrib.contenttypes

Σας επιτρέπει να αναπτύξουν τις εφαρμογές σας ως αυτόνομες μονάδες. Αυτό είναι ό, τι οι προγραμματιστές Django χρησιμοποιείται για να επιτρέψει Django ενσωματωμένο πλαίσιο σχόλιο για να επισυνάψετε ένα σχόλιο για κάθε μοντέλο στο έργο σας.

Για παράδειγμα, αν έχετε κάποιο αντικείμενο περιεχομένου που θέλετε να «αποδίδουν» σε άλλα αντικείμενα περιεχόμενο των διαφόρων ειδών, όπως επιτρέπει σε κάθε χρήστη να αφήσει ένα «αγαπημένο» αστέρι σε ένα blog post, η εικόνα ή το προφίλ του χρήστη, μπορείτε να δημιουργήσετε μια Favoriteμοντέλο με ένα γενικό πεδίο σχέση με αυτόν τον τρόπο:

from django.db import models
from django.contrib.auth.models import User
from django.contrib.contenttypes.models import ContentType
from django.contrib.contenttypes import generic

class Favorite(models.Model):
    user = models.ForeignKey(User)
    content_type = models.ForeignKey(ContentType)
    object_id = models.PositiveIntegerField()
    content_object = generic.GenericForeignKey('content_type', 'object_id')

Με αυτόν τον τρόπο μπορείτε να προσθέσετε ένα Favoriteαστέρι από οποιονδήποτε χρήστη σε οποιοδήποτε μοντέλο στο έργο σας. Αν θέλετε να προσθέσετε πρόσβαση API μέσω της τάξης μοντέλο παραλήπτη μπορείτε είτε να προσθέσετε μια αντίστροφη γενικό πεδίο σχέση με το μοντέλο παραλήπτη (αν και αυτό θα ήταν «σύζευξη» τα δύο μοντέλα, τα οποία είπατε ότι ήθελε να αποφύγει), ή να κάνετε την αναζήτηση μέσω του Favoriteμοντέλου με το content_typeκαι object_idτου αποδέκτη παράδειγμα, βλέπε τις επίσημες docs για ένα παράδειγμα.

Απαντήθηκε 09/12/2008 στις 19:01
πηγή χρήστη

ψήφοι
3

Δεν υπάρχει τίποτα λάθος (IMHO) με κάνει κάποια εφαρμογή εξαρτάται από την άλλη. Μετά από όλα, οι εφαρμογές είναι μόνο λειτουργίες σε μια σειρά από μοντέλα. απλά πρέπει πάντα να γνωρίζουν ποια app εξαρτάται σε ποια app (Υποθέτω ότι θα μπορούσαμε να ονομάσουμε αυτό ένα χάρτη εξάρτηση).

Μπορείτε να επιτύχετε χαλαρή σύζευξη με το πλαίσιο CONTENTTYPES. Επιτρέπει σε μια εφαρμογή να είναι αληθινά φορητό / συνδεόμενο όμως ακόμα ενσωματωθεί με άλλες εφαρμογές.

Έγραψα ένα σχόλιο εφαρμογή (ναι, εγώ εκ νέου εφηύρε τον τροχό), τα οποία μπορούν να ενσωματωθούν σε οποιαδήποτε άλλη εφαρμογή, με λίγες γραμμές στο πρότυπο της σελίδας όπου τα σχόλια θα πρέπει να δημοσιεύονται (χρησιμοποιώντας προσαρμοσμένες ετικέτες).

Ας πούμε ότι θέλετε ένα μοντέλο «νήμα» να είναι συνδεόμενο σε οποιοδήποτε άλλο μοντέλο. Η ιδέα είναι να δημιουργηθεί το ηλεκτρονικό γενική ξένο κλειδί (ανατρέξτε στην τεκμηρίωση του Django σε αυτό), και να γράψουν μια μικρή λειτουργία που παίρνει κάθε αντικείμενο και επιστρέφει ένα «νήμα» που αντιστοιχούν σε αυτό (ή δημιουργεί ένα, αν είναι απαραίτητο), και να γράψει μια ετικέτα προσαρμοσμένο πρότυπο που χρησιμοποιεί αυτή τη λειτουργία, για παράδειγμα {% get_thread for arbitrary_object as thread %}. Όλες οι δημοσιεύσεις που σχετίζονται με ένα νήμα, η οποία σχετίζεται με το αντικείμενο, το οποίο μπορεί να είναι οποιουδήποτε τύπου.

Μπορείτε να σκεφτείτε το «νήμα» αντικείμενο ως ένα είδος πληρεξουσίου, έτσι ώστε αντί να έχουν μια θέση να σχετίζονται με ένα συγκεκριμένο «άρθρο» ή «ανάρτηση ιστολογίου», είναι ακριβώς σχετίζεται με μια κλωστή, η οποία είναι αφηρημένη κατά μία έννοια , τι είναι είναι ένα νήμα; Είναι απλά μια συλλογή των θέσεων. Το νήμα στη συνέχεια επιτρέπει στον εαυτό του να συνδέεται με οποιοδήποτε αντικείμενο ανεξάρτητα από τον τύπο του. (αν το κάνει περισσότερο από αυτό, θα μπορούσε να κρατήσει επιπλέον πληροφορίες όπως επιτρέπει / απαγορεύοντας ανώνυμο. θέσεις εργασίας, το κλείσιμο / άνοιγμα σχόλια στη σελίδα, κλπ ..)

ΕΠΕΞΕΡΓΑΣΙΑ

Εδώ είναι το πώς μπορείτε να δημιουργήσετε μια γενική ξένο κλειδί με το πλαίσιο τύπους περιεχομένου:

from django.contrib.contenttypes import generic
from django.contrib.contenttypes.models import ContentType

class Thread( models.Model ):
    object_type = models.ForeignKey(ContentType)
    object_id = models.PositiveIntegerField()
    object = generic.GenericForeignKey('object_type', 'object_id')

Μπορείτε να κάνετε πιο «διαφανής» με την αξιοποίηση της σιωπηρής «κοινή» interface που Django αναλαμβάνει όλα τα αντικείμενα εφαρμογή ..

    #inside the Thread class:
    def __unicode__(self):
        return unicode(self.object)
    def get_absolute_url(self):
        return self.object.get_absolute_url()
Απαντήθηκε 09/12/2008 στις 19:35
πηγή χρήστη

ψήφοι
3

«Είναι αυτό που έγραψα πιο πάνω, εισάγει ένα μοντέλο από μια άλλη εφαρμογή και να ορίσετε ως ξένο κλειδί, πώς Django εφαρμογές αλληλεπιδρούν;»

Ναι. Δουλεύει για μένα.

Έχουμε περίπου 10 αιτήσεις που δανείζονται εμπρός και πίσω μεταξύ τους.

Αυτό οδηγεί σε ένα είδος εξάρτησης σε δοκιμή μονάδα σενάριο μας.

Μοιάζει με αυτό.

  • "ιδιοκτησία". Έχουμε μια απλή εφαρμογή κυριότητα δεδομένων που ορίζει κάποιες βασικές έννοιες της ιδιοκτησίας που άλλες εφαρμογές εξαρτώνται. Υπάρχουν μερικές απλές πίνακες εδώ.

  • "πράγμα". [Δεν είναι το πραγματικό όνομα]. εφαρμογή πράγμα που μας έχει στοιχεία δεδομένων που ανήκουν σε διαφορετικές ομάδες χρηστών. Υπάρχουν πράγματι πολλά πολύπλοκα τραπέζια το μοντέλο για αυτήν την εφαρμογή. Εξαρτάται από την «ιδιοκτησία».

  • «Πίνακες». [Δεν είναι το πραγματικό όνομα]. Μερικοί από τους χρήστες μας δημιουργούν αρκετά περίπλοκα μοντέλα off-line (πιθανώς με υπολογιστικά φύλλα) και να ανεβάσετε τα αποτελέσματα της μοντελοποίησης σε «πίνακες». Αυτό έχει ένα σύμπλεγμα από αρκετά περίπλοκο πίνακες. Εξαρτάται από την «ιδιοκτησία».

  • "αποτέλεσμα". [Δεν είναι το πραγματικό όνομα]. Τα αποτελέσματά μας βασίζονται σε πράγματα που έχουν ιδιοκτήτες. Τα αποτελέσματα βασίζονται σε πράγματα και τα τραπέζια, και οι απαντήσεις στα αιτήματα των πελατών. Αυτό δεν είναι υπερβολικά περίπλοκο, ίσως μόνο δύο ή τρεις βασικούς πίνακες. Εξαρτάται από «πράγματα» και «τραπέζι». Όχι, δεν εντελώς αυτόνομα. Ωστόσο, υπόκειται σε περισσότερες αλλαγές από ό, τι τα άλλα πράγματα για τα οποία εξαρτάται. Γι 'αυτό είναι ξεχωριστό.

  • "επεξεργασία". Έχουμε προγραμματίσει και να παρακολουθούν μεγάλες εργασίες παρτίδα. Αυτό είναι σε αυτή την εφαρμογή. Είναι πραγματικά γενική, και μπορεί να χρησιμοποιηθεί σε μια ποικιλία τρόπων. Βρίσκεται εντελώς μόνος.

  • "καλως ΗΡΘΑΤΕ". Έχουμε ένα «καλωσόρισμα» app που παρουσιάζει μια δέσμη κυρίως στατικές σελίδες. Αυτό δεν έχει πάρα πολλά τραπέζια. Αλλά είναι για δεύτερη ενσάρκωση αυτό επειδή το πρώτο ήταν πάρα πολύ περίπλοκη. Βρίσκεται εντελώς μόνος.

Η μόνη σχέση μεταξύ των εξαρτώνται από τις εφαρμογές είναι μερικά ονόματα πίνακα. Όσο συντηρούμε τους πίνακες αυτούς (και τα κλειδιά τους) μπορούμε να αναδιατάξετε άλλες εφαρμογές όπως το δοκούν.

Απαντήθηκε 09/12/2008 στις 19:06
πηγή χρήστη

ψήφοι
2

Ο κωδικός σας φαίνεται σωστή. Θα ήθελα να κρατήσει τη θέση και το σχόλιο σε ένα blog app όμως. Δεν λέω ότι αυτό είναι ο τρόπος Django, αλλά αυτά τα μοντέλα είναι αρκετά κοντά για να είναι στην ίδια εφαρμογή.

Πώς να χωρίσετε το σχέδιο

Θα ήθελα να διαχωρίζει μια εφαρμογή, αν?

  • Σκοπεύω να το σχεδιασμό Resuable. (Και να προσπαθήσουμε χαλαρή σύζευξη)
  • (Για τα μεγάλα έργα) Αποτελείται από ένα μεγάλο τμήμα του έργου.

Αφ 'ετέρου; έχει πολλά μικροσκοπικά εφαρμογές (όπως μια εφαρμογή με ένα μόνο μοντέλο και δύο προβολές) είναι δύσκολο να διαβαστεί και να διατηρήσει IMHO.

Πώς Apps θα πρέπει να αλληλεπιδρούν

Αυτό εξαρτάται από τον τύπο του έργου και το είδος της εφαρμογής και πάλι. Για παράδειγμα, αν μια εφαρμογή εξαρτάται σιωπηρά σε ένα άλλο (δηλαδή όχι γενόσημα) η εισαγωγή και χρησιμοποιώντας αναφορές από την άλλη app είναι αποδεκτή. Στην περίπτωση αυτή η δεύτερη εφαρμογή μπορεί να εγκατασταθεί μόνο του, αλλά η πρώτη χρειάζεται την παρουσία του δεύτερου.

Αν θέλετε να κάνετε μια εφαρμογή εξαιρετικά επαναχρησιμοποιήσιμα και γενικής χρήσης, όπως ένα σχολιάζοντας εφαρμογή, ίσως χρειαστεί να ενταχθούν κάποια μηχανισμό ρύθμισης. Ίσως κάποιες νέες ρυθμίσεις ή πρόσθετη ρύθμιση παραμέτρων URL, ή μια ειδική οδηγία / μέθοδος για τα μοντέλα σας ... django.contrib.adminείναι ένα καλό παράδειγμα για αυτό.

Οι εφαρμογές δεν πρέπει να αλληλεπιδρούν αν δεν είναι απαραίτητο όμως. Σχεδιάζοντας εφαρμογές για να αποφευχθεί η άσκοπη σύζευξης είναι πολύ χρήσιμη. Βελτιώνει την ευελιξία της εφαρμογής σας και καθιστά πιο διατηρήσιμη (αλλά πιθανώς με υψηλότερο κόστος για την ενσωμάτωση).

Απαντήθηκε 09/12/2008 στις 18:45
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more