※ 本記事は意見や解決策は一切提示しません。
DRF(Django REST Framework)は、単純なCRUDのREST APIを実装する際にはかなりコーディングレスに実装できる点は長所だと思う反面、DRF自体の設計思想の特殊性ゆえに、ある程度のビジネスロジックを書かなければならないときにどこに書くかというのは、結構悩ましい問題だと思う。
DRFのチュートリアルや入門書で紹介されているサンプルコードの多くは、本当にシンプルなCRUDのREST APIであり、そういう場合はDRFを使うとほぼロジックを書かずに実装できてしまうので、DRFが便利に感じる。
しかし、現実の世界で使われるAPIを実装する場合は、ある程度の複雑なビジネスロジックを書かなければならないことの方が多く、単純なCRUDで済むことはむしろ稀なのではないかと思う。
ビジネスロジックを書く場所としては、少なくとも原理的には
- APIViewのget,postなどのメソッド内に書く。
- APIViewの特定のメソッドをオーバーライドしてその中に書く。
- Serializerの中に書く。
といった選択肢がある。(使用するAPIViewやSerializerにもよる。)
※ ビジネスロジックレイヤー(Service、Query、Commandなど)を追加して、その中にビジネスロジックを書く場合も、最終的にビジネスロジックレイヤーをどこから呼ぶかは考える必要がある。
みんなはこの辺で悩んでないのかな？と思って調べて見たところ、日本語の記事は見つからなかったが、英語の記事はいくつかヒットしたり、2018年のEuro Pythonでこのテーマについて発表している人がいたりしたので、海外ではそれなりに関心のあるトピックのようだった。
www.youtube.com
stackoverflow.com
stackoverflow.com
breadcrumbscollector.tech
特にこの「Django structure for scale and longevity」という発表はYouTubeで視聴したがとても考え方の参考になった。(タイトルだけ見るとDjango全般の話のようだが、実質ほぼDRFの話だった。)
とりあえず、他にも疑問に思っている人がいるということが分かって安心した。
私はまだそれほどDRFを使い込んでいる訳ではないので、もう少し詳しくなったら、改めて自分なりの意見を記事にしてみたい。
