0

FOS USerBundle を使用したいのですが、アプリケーションにログインできるさまざまな種類のユーザー (学生、教師、ディレクターなど) がいます。次に、それぞれに固有の異なるプロパティがあります。

私が見るように、いくつかのオプションがあります：

オプション 1 - FOS\UserBundle\Entity\User を継承する User エンティティ (および FOS UserBundle の user_class として config.yml に設定) を持つには、ROLE によって区別されるさまざまな種類のユーザーのすべてのプロパティを使用します。私は特にこのオプションが好きではありません.Userエンティティは、システムにユーザーがログインするたびにnullで多くのプロパティを持ちます.未使用になります。

オプション 2 - FOS\UserBundle\Entity\User を継承する User エンティティを作成する (および FOS UserBundle の user_class として config.yml に設定する) には、アプリケーションの各アクター (学生、教師、ディレクターなど) に対して 1 つのエンティティを作成します。 User エンティティとの OneToOne の関係。このようにして、ユーザーがログインするたびに、ログインしたユーザーの種類に応じて、$logguedUser->getStudent() または $logguedUser->getTeacher() などと言うことができます。

オプション 3 - FOS\UserBundle\Entity\User を継承するユーザー エンティティを作成するには、アプリケーションの各アクター (学生、教師、ディレクターなど) に対して 1 つのエンティティを作成し、そのエンティティのそれぞれがユーザーから継承します。これは理論的にはより良いオプションですが、構成ウィッチで FOS UserBundle が user_class であると言う必要があるため、それを実装する方法を理解することはできません。 . アクターがアプリケーションにログインしたとき、どのオブジェクトがログに記録されますか?

誰かがより良いオプション、または3番目を実装する方法、または1つをサポートする方法を持っていますか? 送信

4

1 に答える 1

0

最初のオプションは怠惰なプログラマ向けです。3 番目のオプションは、ユーザー タイプごとにアクセスを区別することにあまり関心がなく、過剰な構成も必要になるため、適切ではありません。

個人的には 2 に賛成です。継承ですべての問題を解決できるわけではありません。進化するアプリケーションは、生徒が教師になれない、または他の役割 (または複数の役割) が存在し、継承がケージになることを意味するわけではありません。いくつかのOneToOne 関係を行うことができ、残りは Doctrine が行います。

オプション4があります:)教義は継承マッピングに関するいくつかの解決策をまだ許可しており、継承を使用したい場合は単一テーブル継承があなたのために行うことができます

于 2013-09-06T17:53:13.947 に答える