00:07
はい、みなさんこんにちは。kkeethことくわはらです。
本日もやっていきましょう。kkeethのエンジニア雑談チャンネル。
この番組では、ウェブ業界やエンジニアリング、
いろんな技術についての情報を雑談形式で
発信していきたいと思います。
で、今日は、タイトルにあります
ChatGPTで学ぶMV
何たらアーキテクチャのいくつかみたいな話ですね。
で、これ、なんで今日こういう話をしたかというと、
昨日ですね、お昼の時間に
NARSEさんの勉強会がありまして、
結局フルでは参加できなかったんですけど、参加をして、
その時にNARSEさんがいくつかの
ソフトウェアのアーキテクチャパターンというのをお話しされてて、
やっぱり聞いててすごく面白かったんですけど、
僕自身がそれを聞きながら、
例えば、ちゃんと振り返ったりまとめたりしたことなかったので、
自分なりにも調べてみたかったんですけど、
ChatGPTに聞いてみて、ああなるほど、そういう感じなのね
っていうので、学んでいたという感じです。
昨日のちなみに勉強会は、NARSEさん直伝、
2024年最新アーキテクチャトレンドとユースケースを
徹底解説というところで、
彼の動画が多分YouTubeでまたアーカイブ出てくれると思いますので、
それを見ていただくのが一番良いと思います。
僕のは単純に表装を舐めるぐらいの話ですね。
そんなのあるんやっていうのを紹介するぐらいの話で、
僕の場合は終わってしまうと思いますけど、
ご了承いただければなと思います。ではではやっていきましょう。
MVなんちゃらパターンって、調べたら
結構いっぱいあるんですけど、
アーキテクチャパターンでよく聞かれるのは、結局MVっていうモデルビューですね。
MVなんちゃらっていうパターンが
本当に多くて、とにかく大事なのは
モデルとビューと、あとはそれをどう繋ぐか、
そこのどうコントロールしていくのかっていう話に尽きるんだろうな
っていう気はしてます。
なので、ちゃんとGPTにも聞いてみたんですけど、
よく出てくるものとしては、MVCとMVVMと、
あと最近流行っているんですかね、MVPですね。
モデルビュープレゼンター。
これがパッと3つ浮かんでから紹介いただきました。
他にもいくつかあって、
モデルビューアダプターですね。MVAってやつもあったり、
MVVMC、
ゲームツリーとMVVM-Cですね。
モデルビュービューコントローラーコーディネーター
っていうものだったり、あとはVIPERですね。
VIPERっていうアーキテクチャパターンもあります。
VIPERは僕2年くらい前にちょっとお話を聞いて、
そんなものがあるんやねっていうのを伺ったんですね。
ただこれざっくり調べた感じだと、
IOSのアーキテクチャパターンですかね。
で、使われているものっぽい書き方をされて、
そうなの?みたいなのがありますけど。
でもそんなものもあったりするというので、
現代でよく使われているものとしてか、
使われるものとしては先ほど出たMVCとMVVMとMVP
というこの3つのお話ですね。
03:02
僕も軽く調べた感じ、海外の
技術的ブログとかを見た感じ、
この3つを比較されて語られている方とか、
記事を書かれている方の方がやっぱ多かったなって印象はありますね。
チャットGPTもやっぱそれを返してきました。
今回はその3つについてとりあえず触れて、
あと他のやつも軽く概要だけ触れて今日は終わろうかなと思ってます。
最初はMVCですね。
モデルビューコントローラーというやつです。
これは古典的というか、昔からずっとある
モデルビューなんちゃら系の先駆けと言っていいんじゃないかと思いますね。
かなり最初期からあったと思いますけど。
本当に最初期は確かMVからだった気がしますけどね。
今日の内容的にはMVCからですけど、
モデルビューとコントローラーというこの3つに関心どころを分けて、
実装していきましょうという設計の考え方ですね。
メリットとしては分離の明確さがはっきりしていると。
1つはまずモデル。
ビジネスロジックとかデータを管理するとか扱いをするモデルというところと、
ユーザーインターフェースですね。
実際にユーザーが目にして扱う、触るところのビューですね。
あとはその入力処理です。
ユーザーが触った入力したところに対してゴニョゴニョするというコントローラーという
この役割3つに分けるというのが直感的で明確ですよね。
というのが1つのメリットですと。
開発の効率化もしやすいんじゃないのという話をしていて、
明確に役割が分けてあるんだから、
開発もそのまま分割をしてそのままやればいいじゃんというところですね。
3つ目は再利用性と拡張性が挙げられていますと。
コンポーネントが独立をしているため、
再利用と拡張が容易ですよと。
思想的にはそうだよねという感じはありますけど、
この3つがとりあえず挙げられてますねという話でした。
じゃあデメリットはという話ですけど、
デメリットは複雑性が増加しやすいねということでした。
大規模なアプリケーションになるとコントローラーが肥大化する、
ファットコントローラーとかいろんな名前がありますけど、
というものが出てきたりするのでコントローラーがどんどん
でかくなっていって管理難しくなるよねという話はよくあると。
ビジネスロジックの周りのところをデータとモデルでやるといっても、
最終的にはコントローラーで集約するところが多いと思いますので、
コントローラーがでかくなっていくのは仕方ないなと。
そういう複雑性が肥大化しやすいというのが
MVCの一つのデメリットです。
もう一個のデメリットは、ビューとモデルの間接的な依存が
発生しますと。モデルとビューの間で
データ同期を取ったりする必要もあったりするんですけど、
ここがロジカル的に複雑になっていって結局、
ビューとモデルで分けていると言っておきながら、
なんだかんだお互いに依存したいなというところがある。
明確に分けられるのかというとそれはどうなんだろうというので、
概念的には明確に分けられているようには見えますけど、
実際問題はデータとの同期が欲しいよねというのがあって、
割と依存関係になってしまう。
それを巻き取るためのコントローラーがもっと複雑化していく
みたいな話は確かに僕も経験がありますね。
これが1つ目のMVCというものの
メリデメの話でした。
続いて2つ目。2つ目がMVVMですね。
06:01
これもあんまり話聞かなくなりましたし、結構当たり前感もあるし、
いろんなフレームワークがその思想に乗っかって
実装されていたりするのもあるので、僕らは意識しないだけかもしれないですけど、
特にフロントエンド界隈でMVVMというのは
一時期ちょいちょい耳にしていたなという感じですね。
MVVM、モデルビュー、ビューモデルですね。
こちらのメリットとしては、まずデータバインディングという
メリットがあります。ビューモデルを通じて
ビューとモデルがデータバインディングをされるというので、
UIとビジネスロジックの同期がやっぱり自動化されますよね。
データバインディングの概念を実装したのが
旧アングラJSというフレームワークですね。
あいつがデータバインディングというのを実装して、
そこからデータバインディングが割と良さそうだというので、
いろんなフレームワークがそれに乗っかっていた印象はありますし、
今もそういう機能がそもそも備わっていたりするものも多いですよね。
結果リアクトはデータバインディングではなくなったし、
ビューはデータバインディングで確かあった気がしますけど、
リアクトのユーズステイトを使えば、
同期的に管理するデータが変われば、
最近使っているコンポーネントも再描画されるというところがあるので、
実際としてはデータバインディングっぽいものは
実装されていると言ってもいいんじゃないかなと思ったりします。
でもこのデータバインディングが生まれた時は
すごくこれいいじゃんって思いましたね。
なんだかんだビューとモデルってちょっと離れているので、
そこの同期性があるのはやっぱりありがたかったなと思います。
それはさっきのフロントエンドで
SPAというのがもうデファクトになって、
側の方でもデータ管理とか状態管理しなきゃいけなくなったっていうものがあるので、
データバインディングは嬉しいなと思いますね。
その代わりデータをモデル側じゃなくて
ビュー側でもイベント発火して直で変更されるとなると
データのフローがバラバラになって
結構ぐちゃぐちゃになるみたいなお話も別にあったんですよね。
それが出てフラックスという概念が出て
なんたらかんたらというのが生まれたみたいな別の話もありますけど
それは一旦置いておきます。
1つ目のメリットはデータバインディングでした。
2つ目はテストの容易性ってとこですね。
ビューモデルっていうのはロジックをカプセル化してくれるため
UIから独立してテストも実はしやすいよってとこですね。
これも分からなくはないですけど
フロントがビュー側でどこまでテストするのかって結構悩ましかったりしますね。
未だにフロントエンドのテストの流度とか
ベストプラクティスとか
割とまだ固まってない気がしますし
ビュー側の方のテストもしますけど
ビジュアルリグレーションテストでやったりすることもあったりするので
まだそこは難しいですけど
かけって言われればかけなくはないという意味で
確かに容易性は担保しているっていうのはあるかもしれないですね。
3つ目のメリットですけど
3つ目は先ほどと似てます。再利用性の向上ってとこですね。
ビューモデルを通じてビューのロジックを再利用しやすくなるっていう
そのままですね。これは書いてみたら分かります。
概念的にはそうかもしれないですけど
そもそもアーキテクチャパターンで書いている時点で
再利用性っていうのを最初から考えた上での
設計だと思うので、あえて書かなくてもそうだろう
09:02
っていうのはあったりします。実際に再利用が
やりやすくなったというか、実際に
再利用そのものをするのかっていうのは別の話ですよね。
今後再利用するかもしれないし、これは共通化しておいたほうが
いいだろうと思って細分化したんだけど
結果的に1回しか読まれてなかったりとか1ページしか読んでない
みたいなコンポーネントで結構乱立するので
そもそも再利用本当しますかっていうのは
することが求められて初めてコンポーネント化するなど
みたいな考えはあったりはしますけどね。
まあまあそんなことも言いながら
脱線したので戻ってきます。さっきのがメリットなので
MVVMのデメリット2つですね。
1つ目は学習曲線が高いという話です。
データバインディングの概念が初心者には難しい場合があると
言われましたけど、個人的にはそんな感じはしないですし
フレームワークがその辺を割とラップして
機能として提供してくれている、APIがあると思いますので
そんな学習曲線は僕は高くないと思ってますけど
まあ初学者には高いのかもしれないですね。
いきなりMVVMから設計論の世界に入っていけば
そうかもしれないですけど。
ちょっとここは懐疑的かなという印象があります。
自動でデータバインディングが発生します。
それが原因で予期せぬパフォーマンス問題を引き起こすことがある
というのは経験があるのでこれはおっしゃる通りって感じがしますね。
どんな設計したりどんな実装でも
パフォーマンス問題はどうせくっついてくるんですけど
データバインディングとかMVVMの
アーキテクチャーでのパフォーマンス問題はよくある話なので
ここは確かにねって感じです。
全部を同期的にやるってことは結局全部データのやり取りをしなきゃいけないので
また再描画する再レンダリングするコストだったりとか
ドムが増えたりドム操作をしなきゃいけない可能性があって
その時のハイドレーションがまた発生するので
そのコストをまた払わなきゃいけないとなるとパフォーマンスが遅くなる
っていうのもよくある話ですね。なのでパフォーマンスは
本当その通りだと思いました。はい以上MVVMの
メリットデメリットでした。続いて
MVPですね。最近話題らしいです。僕
昨日初めて知りました。MVPモデルビュープレゼンターですね。
こちらのものですけど
メリットとしてはテストのしやすさっていうのが真っ先に上がってきました。
プレゼンターがそのビューのロジックを担当してくれるので
ビューとは独立していることになると厳密に言うと
ビューはそのものビューだけのテストもできまして
プレゼンターがロジカルのところのテストをかけると
MVVMよりもうちょっとビューとそれ以外のところの
分離ができているという話ですね。2つ目は
分離の明確さがはっきりしていると。さっきの話と
似てますけどMVCでも良くないっていうように聞こえますけど
MVCよりももっとビューとモデルの分離っていうのがはっきり明確化
言語化されています。プレゼンターがその中間に
位置をしてくれるっていうところがMVCよりも少し
良いところですねって話でした。デメリットは
MVPはMVCと比較して複雑性が待つことがあると
先にあったフレームワークの
問題点を解決する。解決するための思想ではあるんですけど
結果複雑というか
12:01
柔軟に細かなところまで配慮すると複雑性が
増すのはその通りだというのはあるので。結局こちらも
MVCと同様プレゼンター中間の人たちが
機材化する傾向はあるかもねって
話をしてました。なのでデメリットの解決そのものは
できてないよっていうところですね。あとは実装の難易度が
上がると。ビューとプレゼンターの間の通信を適切に
管理する必要があって実装が複雑になる可能性もありますよね
っていう話をしてました。一応MVP
そのものの説明をされている
お話とかリンクがペラペラ貼られてるんですけど
MVPだけちょっと抜粋して読んでみますかね
MVPとはちなみに従来のMVCパターンの
欠点のいくつかに対処するアーキテクチャパターンでございますと
ビューとモデルの間の関心ごと分離する
その分離自体の改善をすることに
焦点を当てたっていうのが今回のMVPプレゼンターのやつですね
MVCの特殊なものとして
1990年代最初に導入されたと
MVPはアプリケーションのコンポーネントを3つの主要な部分に
分割をしてくれますというので
さっき名前の通りモデルとビューとプレゼンターですと
モデルは何度も言ってますアプリケーションのデータと
ビジネスロジックとかを担保してくれる役割ですね
MVCのモデルもここはよく似てると思います
データ処理したり保存したり管理したり
必要なビジネスルールを実装したりしてくれると
モデルはビューとかプレゼンターと直接通信することはないよ
ってところだけ注意してください独立はしてますよと
ただ呼ばれたらなんかするってことでしょ
ビューはユーザーインタフェースとかプレゼンペーションレイヤーの
お話ですねMVCのビューとここもやっぱり似てます
ビューの主な機能っていうのはモデルから取得したデータを
あくまで表示することですねJSON色付け代わりですね
しかしMVPではビューは
より受動的で更新とユーザー入力処理をプレゼンターにも
依存してしまっているとあーなるほどね
そこがちょっと違うんですねビューはプレゼンターとだけ通信し
モデルとは通信をしないとプレゼンターが
モデルとやり取りをするんですね最後プレゼンターですけど
プレゼンターってのはモデルとビューの橋渡しをしてくれるんですね
MVCにおけるコントローラーの責任の一部も
になっていますとプレゼンターはモデルからデータを
取ってきてビューを更新したり出し
データ表示を保証したりしてくれるとコントローラーと異なるのは
プレゼンターというのはビューからのユーザー入力を直接処理を
してビューとモデルの間の双方向通信というのを
促進しますとでなるとやっぱりプレゼンター確かにちょっと
責務でかい気がしますコントローラーよりも少し複雑度
高いなそうなるかもしれないですねより柔軟な設計とか
細かくプレゼンターを書く必要があるので
1ファイルでプレゼンター処理を書いてしまうと確かにそれは
ファットになるイメージはすごくありますねコントローラーよりも
でかくなるんじゃないかなって気はしましたただ
データの処理をするモデル側の方はプレゼンターと
しか扱わないというのはまずは管理として
データの整合性とか正しさは保ちやすいなって
印象がありますね逆にビュー側から
モデルにやり取りすることがないと分離されているのも正しい
と思いますねMVCとMVPの主な違いというのは
15:01
コントローラーとプレゼンターの役割にあって
プレゼンターというのはユーザーのインタラクションとかビューとモデル
間のデータの流れにより深く関わるようになってビューというのは
自動的なコンポーネントとして残されるこのように
関係性を分離することで各コンポーネントを分離して独立
してテストできるため優れたテスト用意性とモジュール性を
実現することができるとモジュール性とテスト用意性
というのは大体セットになると思うんですけどここから担保できるのが
強めだよという話でしたなるほどね
以上MVPのお話でしたね
他にも調査したら色々あるよという話を冒頭にも言いました
MVVMCというやつですね
モデルビュービューモデルコーディネーター
というのがMVVMCとあとはMVW
というのが実はありますモデルビュー
whateverだった気がしますねぶっちゃけ
MとVってモデルとビューが大事でそれ以外は何でもいいやろ
っていうwhateverのWだった気がしますね
あとモデルビューアダプターですねMVAというやつも
一応ありますこれはでも標準的な
ソフトウェアアーキテクチャパターンとして一般的には認知されてない
と思います僕も名前だけ知っててそんなそういえばあったなっていうの
昨日お話聞きながら思い出した感じですけど
MVAというのはモデルとビューの間の適用レイヤーを
強調する特定のコンテキストとかフレームワークで考慮される
ことがあるけど一般的にはあんまないよということですね
こちらはですねいわゆるソフトウェア工学の文献とか
ドキュメントで基本的なアーキテクチャパターンとして
広く文章化されたりするケースはあんまないよと
特定のフレームワークとかでよくよく見かけられるみたいなことは
ありますけどそれ以外に関してはあんまないというので
もし出てきたらそういうものがあるっていうのを
頭の片爪入れるぐらいでちょうどよいかなって気はしましたね
あとさっき話題に出しましたバイパーと言われるものですね
VIPERというものです一応バイパーの
頭文字何を取ってるかというと
ビューインタラクタープレゼンターエンティティルーター
という5つの頭文字を取ってバイパー
というものですね特に複雑なアプリケーション開発で
使われることが多いととにかく決め細かく関係の分離と
優れたテスト用に重きを置いた
フレームワークなのでそれを求められるような開発現場では
使えるんじゃないのというところでした一応さっきの
言った5つですけど一応ざっくり説明すると
バイパーのVビューですねビューはもちろんユーザーインターフェースを
表示していて入力を受け取って
後に流す役割ですねバイパーのIですけど
これインタラクターと言ってビジネスロジックを担当してくれる
ものですデータ操作をして
プレゼンターに渡してくれるというところですね
3つ目のPプレゼンターですけどこちらはビューからの入力を受け取って
それをインタラクターに渡して反応をビューに
送り返すというところですねちょっと中間層の役割
まさにプレゼンターのところですね実際の処理自体は
インタラクターでやる
バイパーのEこれはエンティティーですこれはアプリケーションのデータモデル
というのを表すというところですね
Rですねルーターですルーターは画面遷移の
ロジックというのを担当してどの画面をいつ表示するか
というところを制御すると
18:01
もうちょっとレイヤーの高いところの扱いをするのがルーターです
エンティティーはもちろんアプリケーションデータモデル
なのでここがコアなところですね5つに決め細かく
分けて設計したい場合はこれを使ってください
もちろん変更容易性は高くなりますし
テストの容易性も高くなるんですけど規模が小さいプロジェクト
だったりすると複雑さがネックになって
フレームワークのために実装してるみたいな形になるので
やっぱり複雑度高いかつ規模感がでかいプロジェクト
の時にこれが効果を発揮するみたいな設計思想バイパー
というのがあります
単一責任原則ってものすごく厳格に適応して生まれたもの
という風に言われてますねというところでした
そんなところで今日はざっと喋っていきましたけど
あくまで今日は紹介でしたので皆さんがどれを使うかというのは
最近僕が使ってなかったMVPってやつを最近知ったので
これを改めて設計パターンとして
実際に適当な自分が作ったアプリケーションで
実装し直してみたいなと思ったりはしましたね
設計方針とかなんだかんだありますけど
基本的には関心の分離と責務をどこまで分けるかというのと
ちゃんと長くソフトウェアを開発を続けていくための
仕組みっていうのを入れたい
それが設計師とかアーキテクチャだと思いますので
何を使うかっていうのは皆さんまたチームの中で考えていただいたり
自分たちでこれがベストだというものをまた
生み出していけばいいと思いますこれは標準としてあるんですけど
それらを自分たちのチームとかプロジェクトでカスタマイズするのは
全然ウェルカムだと思いますのでね
参考に軸となるものを学ぶのはすごく大事だと思ってますので
今日は改めて紹介したというところでした参考になれば
騒がいです
今回はこんなところで終わっていきたいと思います
ではまた次回の収録でお会いしましょう
バイバイ
