MVPって何となく知っているけど、MVCと何が違うか説明出来るレベルじゃないので深掘り
MVPの概要
[M]odel [V]iew [P]resenterの略語、MVCと大きな違いはController→Presenterとなっているところ
MVCでは、UserActionをControllerが受け取り、View/Modelへアクションを繋げていたが、MVPではUserActionはViewで受ける。
但し、依存関係としてView↔Presenter↔Modelの流れなので、Presenter層がView層に干渉できるようにinterfaceを用意してあげ、Presenterから操作可能とする。
MVPのバリエーションは下記２つが存在（普段認識するのは前者）
PassiveView
Viewの中のロジックをなるべくなくし、PresenterがViewのロジック部分を担う（テストしやすいけど、Interface書くの面倒くさい）
SupervisingController
ViewがModelへデータバインディングで取得し、PresenterはModel更新に務める（interface分のコード量は減るけどテストしづらい）
各層の責務
Model
アプリケーションの状態（データとビジネスロジック）を管理
状態変更をPresenterから受け付け
状態変更をPresenterへ通知
外部ストレージ（DB等）へのアクセス
View
UI表示
UserActionの受け付け
UserActionをPresenterへ通知
UserActionをPresenterから受け付け
Presenter
View側のビジネスロジック
ViewとModelの仲介
ViewとModelへの直接参照を避けることでテスト容易性を向上できる
実装してみての感想
メリット
各層を分離することで、主たる役割が明確化されることは保守性や運用性を考えて、コードの見通しが確保される為にだいぶメリットが大きい！
概念として難しいPresenter層は、最初は役割を曖昧に理解してたが、実際に使用してみると案外悩むこと無く取り入れられる。
テスト容易性について、実際にUnitTest、WidgetTest、IntegrationTestのコードも実装してみたけど、UT→Presenter、WT→View、IT→複数Viewを対象にテストを書くことが出来る為、整理して書くことが出来るかなと思う。
デメリット
データバインドの為に各画面にInterfaceが必要となるのが面倒くさい。。
イベントを全てPresenterで担うため、Presenterも画面ありきで作成しなければならない
データバインドについては、状態管理ツールをProviderやRiverpod使えば解決策ありそうかも、、