私は現在、Djangoベースのサイトを設計しています。簡単にするために、ユーザーがログインして他のユーザーにメッセージを書き込むことができる単純なコミュニティサイトであると仮定します。
私の現在の選択は、組み込みのUser-Modelを使用するか、独自の何かを構築するかです。ビルトインからはあまり必要ありませUserん。ユーザー名はありません（電子メールアドレスはユーザー名です）が、複数のユーザー（Facebookなど）が使用できる内部名を設定します。さらに、他の人へのアクセスはグループに基づいていないため、許可システムは必要ありません。したがって、ビルドインの電子メール、名、姓、パスワードのフィールドのみを使用するUserことになり、その他はすべてUserProfileに配置されます。一方、サイトのバックエンドでは、グループベースの許可システムが必要になる可能性があるため、組み込みのユーザーシステムが便利です。
全体として、私は1つのユーザーモデルを構築し、管理者バックエンドへのアクセスにのみビルドインを使用しているように見えます。
私の反射に何か問題がありますか？
私の反射に何か問題がありますか？
はい。
私の現在の選択は、組み込みのUser-Modelを使用するか、独自の何かを構築するかです。
3番目の選択肢があります。
http://docs.djangoproject.com/en/1.2/topics/auth/#storing-additional-information-about-users
他のすべてはUserProfileに配置されます
正しい。
1つのユーザーモデルをビルドし、管理者バックエンドへのアクセスにのみビルドインを使用します
自分で作成しないでください。
これを行う：
ユーザーに関連する追加情報を保存したい場合、Djangoは、この目的のために、「ユーザープロファイル」と呼ばれるサイト固有の関連モデルを指定する方法を提供します。
django-primateの作者として、コメントを追加したいと思います。組み込みのユーザーモデルをjuが簡単に変更できるDjango-primateは、まさにそのためのものです。少し余分なものが必要な場合は、django-primateを使用してください。
しかし、問題はありますが、djangoユーザーモデル自体を変更すること自体はまったく問題ではないと思います。1つの問題は、「ユーザー」がまったく異なり、管理者ユーザーと他のユーザーが関係していないことが多いことです。これにより、たとえば、管理者がログインしてから「通常のユーザー」としてサイトにログインしたい場合に問題が発生する可能性があります。これらのアカウントが関連付けられていることや、管理者ユーザーとして自動的にログインすることは期待されていません。これは理由もなく頭痛を引き起こします。また、推奨される関連プロファイルモデルを実装するために、他の多くの問題が発生します。たとえば、認証デコレータを使用する場合は、すべてのプロファイルにcontribユーザーがあり、すべてのcontribユーザーにプロファイルがあることを確認する必要があります。「ユーザー」のフォームと管理により、これはさらに面倒になります。要するに：通常、このプロセスのある時点で何かがうまくいかないでしょう、それは呪いです。
私は主に、管理者以外の目的でcontribユーザーモデルを放棄しました。別のユーザーモデルを構築することは本当にあなたが望むものですが、そのユーザーの認証部分も必要です。したがって、django contrib Userの一般的な使用法です（間違った理由でそれを使用します）。このような状況にある場合の最善の解決策は、そのカスタムユーザーモデルに対して独自の認証を作成することです。これは実際には非常に簡単であり、このアプローチを十分に推奨することはできません。公式の推奨事項は間違っており、代わりにdjangoに組み込まれているカスタムユーザーモデルを認証するための優れたツールが必要だと思います。
最近作成されたdjango-primateをご覧になることをお勧めします：https ：//github.com/aino/django-primate
私はかつて、デフォルトのモデルを継承して、カスタムユーザーモデルを構築しました。動作しますが、お勧めしません。
現在、いくつかの要件がありますが、時間の経過とともに変更される可能性があります。Djangoのユーザーシステムは非常に単純であり、それを使用すると、最も一般的なユースケースのいくつかにより簡単に適応できます。
考えるべきもう1つの側面は、使用できるアプリケーションがすでにいくつかあり、Djangoのユーザーが必要になる可能性があることです。独自のモデルを使用すると、そのようなモジュールの使用がはるかに困難になる可能性があります。
一方、現在の要件に準拠するためにDjangoのユーザーシステムをハッキングするのは難しい場合があります。
さらに、「Custom-User」を「Django-User」に移行することは常に可能であるため、実際にはそのドアを閉める必要はありません。
全体として、それは本当に「ユーザー」の意味に依存すると思います。
登録だけを意味し、Djangoのコア機能との実際の相互作用がない場合は、特に少ない労力でいつでも移行できるため、別のモデルで十分だと思います。
ただし、アプリケーションで「ユーザー」がDjangoの目的と非常によく似たものにマップされる場合は、Djangoユーザーモデルを使用します。