こんにちは！
最近はブログ記事をなかなか上げられていなかったですが、これからは短めの記事をできるだけ頻度高く更新していきたいと思っております。
さて、今回は僕が実際の開発現場に入って経験したLaravelのMVC設計の考え方について、新たな知見を得たのでここに記したいと思います。
Serviceの導入について
LaravelやRailsなどで開発を進めていく際に通常はMVCといって、Model・View・Controllerで役割分担をし、開発を進めていくことが一般的かと思います。
僕が入った開発現場ではControllerとModelの間にServiceとRepositoryを導入し、Controllerにできる限りビジネスロジックを記述せずにServiceにロジックを書くような設計になっており、Controllerの役割をさらに細分化した設計になっておりました。
なので、Controllerには基本的にはほとんど記述せず、ControllerではほとんどreturnでデータをViewに返すだけのコードになっており、非常にシンプルにまとまって感動したのを覚えております。
自分は現場での開発経験がなかったため、MVC以外の要素を入れて開発を進めるということが非常に新鮮でした。
Repositoryの導入
Controllerの一つ下の階層にはServiceがありますが、そのさらに下の階層にはRepositoryがあり、こちらのフォルダでは基本的にはDBにアクセスしたり、DBのデータを加工したりなどしているフォルダになっております。
しかし、直接DBとデータをやりとりしているわけではなく、あくまで直接DBとデータのやりとりをしているのはModelであって、Repositoryはその1つ抽象化された処理をしてServiceにデータを送っているようなイメージです。
ServiceとRepository導入のメリット
ServiceとRepositoryの説明ちょっとわかりにくいでしょうか。
より具体的に説明すると、例えば、ModelでDBとデータのやりとり(処理)をするscopeを作成し、そのscopeを使ってRepositoryでデータを加工し、Serviceで加工したデータを具体的な変数に入れ込んでControllerに渡し、ControllerでそのデータをViewに送るようなイメージですかね。
ServiceとRepositoryはControllerの機能をさらに細分化したような役割を持っており、このように役割をさらに細かく分類することで、Controllerでコードがごちゃつかず、それぞれのファイルでコードがシンプルになり、可読性が増すというのがServiceやRepositoryを導入するメリットかなと思います。
より複雑な機能を持ったシステムを開発するような場合はぜひ活用してみるといいかもしれません。
ではでは、今日はこの辺で！
コメント