Symfony4のログイン周りの実装のサンプルを作った
最近書いているような実装方法でSymfony4のサンプルコードを書いてみました。 GitHub - polidog/sf4-login-sample
サンプルを作ったきっかけは以下のツイート。
Symfonyの認証まわり実装するときにUserエンティティにUserInterfaceをimplementsしなきゃいけないの辛い。
— ポリドッグ (@polidog) July 24, 2018
Symfonyとドメイン的なエンティティが分離している状態でなのに、ログイン関連の実装するときはSymfonyのSecurity
コンポーネントのUserInterafceが必須になってしまう。
これは外部のライブラリに依存してしまっている状態なのでなんとかしたかった。
そんな気持ちから「僕の考えた最強のしんふぉー」って感じでサンプルコードを実装してみようという気持ちでサンプルの実装をしてみました。
ディレクトリ構造
基本的にはsymfonyの標準的な構造になっています。
若干違うところは以下の通りです。
- src:ディレクトリがSymfonyに依存する部分の実装
- src_domain: がコアレイヤ的な実装が入っている
というところでしょうか。
それに合わせてテストも「tests」と「tests_domain」に分かれています。
自分の中のsrc_domainでの実装ルール
外部ライブラリに依存する場合は、基本的にはこちらからInterfaceを提供して直接は依存しないようにする。
このルールを基本として実装しています。
認識している問題点
今の所ざっと思いつく問題点が2つあります。
結局インターフェースを見出すのが、フレームワークやライブラリによってである。
PasswordEncoderInterfaceは明らかにSymfonyのPasswordEncoderInterfaceに依存しないように用意している。
つまりSymfonyの認証周りの実装が違ったらもっと違うインターフェースを用意してただろう。
って思うと設計の時点でSymfonyに依存しているのでは?
しかしそれは果たして悪いことなのだろうか。
フレームワークを使う時点である程度の影響を受けることは仕方ない。
ただ、実装として依存していないことが大切なのでは?
どうするのがいいのでしょうか?だれか教えてください。
Doctrineには依存してしまう問題。
AnnotationとDoctrineのCollectionオブジェクトは依存してしまいます。
これはあえて依存させてたりします。
Annotationなので、実装コードとしては影響がないという事で僕はあえて依存させています。
Collectionは今回の実装サンプルでは出てきませんが、通常はHasManyやMenyToOneは大体あるわけで必ずCollectionが出てくる場面ってあります。
その時は外部にはDoctrineのCollectionではなくtoArray()でArrayに変換するぐらいでいいのかなぁと。
最後に
これが正解ってわけじゃないし、今の自分としてはこういう実装している程度なのでこれからもどんどん変化していく気がします。
あとFeedbackというかPull Request待っているので、ここもっとこうした方がいいとかそういうの教えてもらえると嬉しいです。