Hinweis: Wenn Sie versucht sind, diese Frage zu beantworten, indem Sie mir sagen, dass Sie django.contrib.auth nicht mögen, dann fahren Sie fort. Das wird nicht hilfreich sein. Ich bin mir der Bandbreite und Stärke der Meinungen in dieser Angelegenheit bewusst.
Nun die Frage:
Die Konvention besteht darin, ein Modell UserProfile mit OneToOne to User zu erstellen.
In jeder denkbaren Weise ist ein effizienterer und effektiverer Ansatz, den Benutzer in eine Klasse zu unterteilen, die man für jeden Menschen im System verwenden möchte - eine Klasse namens "Person" (Benutzer).
Ich habe keine zusammenhängende Erklärung dafür gefunden, warum das erstere konventionell ist und das letztere als ein Hack betrachtet wird. Vor einiger Zeit bin ich zum OneToOne-Ansatz übergegangen, um die Möglichkeit zu bekommen, get_profile () zu verwenden, und ich bedauere es seitdem. Ich denke über einen Wechsel zurück, es sei denn, ich kann den Vorteil dieses Ansatzes verstehen.
Sie wissen, dass dieses Modell-Unterklassenverfahren mithilfe einer OneToOne-Beziehung unter der Haube implementiert wird? Was die Effizienz betrifft, kann ich zwischen diesen beiden Methoden überhaupt keinen Unterschied erkennen.
Das Subclassing bestehender konkreter Modelle ist meiner Meinung nach ein hässlicher Hack, der möglichst vermieden werden sollte. Dabei wird eine Datenbankbeziehung ausgeblendet, so dass unklar ist, wann ein zusätzlicher Datenbankzugriff ausgeführt wird. Es ist viel übersichtlicher, die Beziehungen explizit zu zeigen und auf sie explizit zuzugreifen, wo es nötig ist.
Nun möchte ich als dritte Alternative ein völlig neues Benutzermodell zusammen mit einem benutzerdefinierten Authentifizierungs-Backend erstellen, das anstelle des Standardmodells Instanzen des neuen Modells zurückgibt. Um ein Backend zu erstellen, müssen nur ein paar einfache Methoden definiert werden. Das ist sehr einfach.
Es gab nie wirklich eine gute Erklärung, zumindest aus "offiziellen" Quellen, warum in der Praxis Unterklassen von Benutzern weniger nützlich sind als ein UserProfile.
Allerdings habe ich eine Reihe von Gründen, die auftraten, nachdem ich selbst entschieden hatte, dass der Subclassing-Benutzer "der Weg zu gehen" war.
django.contrib.auth.models.User ist. Meistens ist dies in Ordnung, es sei denn, dieser Code ruft Benutzerobjekte ab. Da wir eine Unterklasse sind, sollte jeder Code, der nur unsere Benutzerobjekte verwendet, in Ordnung sein. Sie können also sagen: "Mein Projekt wird immer nur die eine Benutzer-Unterklasse haben". Das ist was ich dachte. Jetzt haben wir drei, plus regelmäßige Benutzer und möglicherweise einen vierten. Anforderungen ändern , müssen die Menge an Code ändern, damit nicht viel Spaß macht.
Hinweis: In letzter Zeit gab es eine Menge Diskussionen über Django-Entwickler über eine bessere Lösung der Probleme im Zusammenhang mit dem Benutzermodell von contrib.auth.
Ist es effizienter und effektiver, das Benutzermodell zu erben? Ich verstehe nicht warum, aber ich würde gerne Ihre Argumente lesen. IMNSHO, Modellvererbung war schon immer ein Schmerz.
Aber das beantwortet vielleicht Ihre Frage nicht, aber ich bin ziemlich zufrieden mit der Lösung, die Will Hardy in diesem Snippet vorgeschlagen hat . Durch die Nutzung von Signalen erstellt es automatisch ein neues Benutzerprofil für jeden neuen Benutzer.
Der Link wird wahrscheinlich nicht verschwinden, aber hier ist meine etwas andere Version seines Codes:
%Vor%Natürlich geht jeder Kredit an Will Hardy.
Tags und Links django django-models django-authentication django-users django-contrib