swift-developers-japan - architecture

MVVM/MVPの話題で「1つのViewControllerにつき1つのプレゼンター（ViewModel/Presenter）」にしたい/したくない、みたいな話で意見があれば聞きたいと思ってます。ちなみに私は1:1にしたくないと思っていて、その理由は保守性の観点で複雑な画面に応じて複雑なプレセンターを作ってしまうと保守運用が大変だから、という気持ちです

1:1にしたい理由を推測すると、画面仕様を把握する際に、ViewModel/Presenterに画面に必要なロジックの呼び出しが一つにまとまっているという利点があるるんじゃないかと想像しています。

8:35 AM

1:1にして、階層化して子供のViewModel/Presenter作りたいというのも上の理由かなと想像してます

8:40 AM

これダミーの画面みたいのを用意してそれについて話すともっと具体的かもしれませんね...

@yimajo さんの「1:1にしたくない」は、「1:nでもいい」ということですよね？「n:1でもいい」ではなくて。

9:49 AM

ぼくはMVVMを、UIと切り離してテストを書けるという点が大きなメリットだと考えていて、その観点では、ViewControllerとViewModelは表裏一体と思っていたので、1:1以外をあまり考えたことがなかったです。

9:50 AM

でも、1つのViewControllerにn個のViewModelがあったとして、それらViewModel間で特に状態やデータのフローがないのなら、1:nでもぼくの目的（UIと切り離してテストが書ける）は果たせるなと思いました。

はい。そうです。 > 「1:1にしたくない」は、「1:nでもいい」ということですよね？

（共通する）状態やデータフローがない、っていう表現は良さそうですね。関連性があるなしの定義のひとつとして明確に示せそうです

@yimajo MVVMだとVに対するVMなのでVCを一つのVとして取り扱うかということになると思います。私はVCはVではないと考えているので、VMは複数存在しうると考えています。ただ、VCに対してVMが存在するのではないので1:nという表現がしっくりきません。 MVPではないですがVIPERではPresenterに対するVの役はVCが担うと設計されているようで、その場合はPとVC（実際はV）は1:1だと思います。つまりそのアーキテクチャにおいてVCはVであるかで判断されるように思います。

SwiftUIでアプリを開発されてる方、アーキテクチャパターンは何か採用されてますか？

12:13 PM

UIKitでは基本はMVCですが、SwiftUIで素の状態（？）はなんと呼べば良いのでしょうか。Document-Viewパターンっぽさもありますが、ちょっと違いますよね。

@rizumita コメントありがとうございます。Discordすごく久しぶりに開いてメンションされてるのに気が付きました。そういえば最近だと私もVIPERだと一つのViewにつきPresenter 1つでやってました。

1

VIPER初心者です。質問させてください。 AViewがもっている状態を、別のBViewで発火したイベントで使いたい場合があると思うのですが、BViewPresenterにAViewの弱参照をもたせるのがセオリーなんでしょうか？ Presenterの責務は「ユーザーの操作やイベントを受け付けてInteractorにビジネスロジックの依頼をし、Viewに描画指示をする」だと理解しています。そのため、単にViewの状態を取得するということをPresenterが行ってもよいのか気になっています。他によい設計があれば教えていただけないでしょうか。

VIPERはくわしくないですが（ Clean Architecture の派生ということからの推測で話すと）、依存の方向は View から Presenter なので、 Presenter が View を持っているのはおかしくないでしょうか。プロトコルを介して保持しているということでしょうか？あと、「AViewがもっている状態を、別のBViewで発火したイベントで使いたい」については、この「状態」は Entity や Interactor が持っているべきものではないですか？間違っていたらすみません。

Presenter が View を持っているのはおかしくないでしょうか。プロトコルを介して保持しているということでしょうか？

私の説明不足ですいません。仰る通り、プロトコルを介して保持しています。

この「状態」は Entity や Interactor が持っているべきものではないですか？

そこもよく理解できていません。 DatabaseやUserDefaultに永続化するデータはEntityとしてInteractorから保存/取得するものだと理解しています。ただメモリ上にもっておきたいだけのデータ、例えばラジオボタンのように、どのViewが選択されている、といった状態もInteractorから保存/取得すべきなのでしょうか。

通常のラジオボタンであれば、たとえば送信ボタンが押されるまでは選択されても特にイベントを通知せず、送信ボタンが押されるというイベントによって初めてどれが選択されているかという情報が通知されるのではないでしょうか。

2:53 AM

しかし、もしラジオボタンの選択によって動的に状態が変更されるようなものであれば、ラジオボタンの選択をイベントとして通知し、 Interactor がそれによって状態を更新するように思います。

Interactor がそれによって状態を更新するように思います。

なるほど。理解できてきました。 View内部で閉じる状態変更であれば、Viewの中で状態管理すればよくて、他のViewへ影響がある状態変更の場合は、別のところで状態管理した方がいい、ということですね。この状態をどこにもたせるかを考えた場合、iOSで気軽に使える共通メモリ領域はUserDefaultsになるのでしょうか？ (edited)

UserDefaultsに保存すると永続化されてしまうので、今やりたいことと違う気がします。

3:20 AM

Interactor がプロパティとして保持するとかでしょうか。

それで十分そうです。ありがとうございます。

1

viperに関して質問です。 Interactorは各Viewと１対１になるわけではないということですが、一つのViewがIntercatorを複数持つというので構わないのでしょうか。 DIする時に、多くのIntercatorを持たせるみたいな形式になるのが違和感があるのですが。

Interactorはビジネスロジックを担当しているので、その分割単位は必ずしもViewの分割単位と一致しないと思ってます。なので、View : Interactor = 1 : Nになっても問題ないと理解しています。

なるほど、ありがとうございます。共通で使うメソッドがある場合、Intercatorを使い回すというイメージなんですね。結構、細分化するようになりそうで、なかなかファイル数が膨大になりそうです、、。

SwiftUI向けのアーキテクチャを考案してみました（アーキテクチャどんどん出過ぎw https://github.com/el-hoshino/ViDRep-Sample

el-hoshino/ViDRep-Sample

ViDRep is an experimental architecture designed for SwiftUI. This is a sample project to show how to build an app using ViDRep - el-hoshino/ViDRep-Sample

9

1

もしかしてですが、現状のTCAって特定の実装をすると爆発的にメモリリークをするような罠があったりしますか？

3:26 AM

TCAにアーキテクチャを変更したバージョンをリリースしてから、FirebaseのログにRAMの空き容量が 0Byte になっているものが大量に湧き始めた気がしています。

メモリーリークとは違うかもですが、実装の仕方によってはパフォーマンスが落ちてしまうらしいです。

Storeを不用意に生成してしまうと、アプリのパフォーマンスが劣化する原因となってしまいます。

https://qiita.com/takehilo/items/e45f29dfc9525f31bf28 (edited)

1

関係ないかもですが、だいぶ前に巨大なStateを使った時にクラッシュすることがあって、リンク先のCopyOnWriteBoxで対応できました。 https://forums.swift.org/t/large-structs-and-stack-overflow/44820/7

Large structs and stack overflow

We have now added a CoW struct that we can use to wrap heavy structs and give them copy on write behaviour. @dynamicMemberLookup struct CoW { init(_ value: T) { _storage = Storage(value) } public subscript(dynamicMember keyPath: WritableKeyPath) -> V { get { value[keyPath: keyPath] } set { value[keyPath: keyP...

1