アーキテクチャパターン

宣言的UIフレームワークのアーキテクチャパターン考察

この記事では宣言的UIにどのアーキテクチャパターンが良いかを述べるのではなく、宣言的UIでのアーキテクチャパターンの課題とアドバイスを記しています。 概論私はiOSネイティブアプリのプログラマでした。現在でも個人ではSwiftUIでアプリを作成していますが、業務ではFlutterアプリを作成しています。ですのでAndroidネイティブのことはわからないのでiOSとFlutterを主に話題にします。 iOSのUIKitではMVCが標準のアーキテクチャパターンでした。一方SwiftUIやFlutterは標準のアーキテクチャパターンが存在しません。存在しないとどうなるのでしょうか。去年私が引き継いだFlutterプロジェクトが、存在しない場合の最悪な実装を示してくれました。 簡単に述べると「WidgetがAPIアクセスを行い、JSONから子Widgetが生成され表示する」という実装です。当然Widgetは肥大化してスパゲッティコードになっていました。 UIKitではMVCのCが肥大化する問題が注目されていますが、標準アーキテクチャパターンが存在することで少なくともVとCは分離され、Vの見通しはある程度良い状態が保たれていました。 React Nativeは詳しくないのですがReactと同様にReduxが一般的のようで、Reduxに乗ってしまえば設計に関して問題は発生しにくいと言えます。 しかしSwiftUIやFlutterでは上記のようなVにすべてを載せてしまう実装まですでに発生しているのです。この2つのフレームワークではアーキテクチャパターンによる設計を十分検討して適用する必要があると言えます。 MVSwiftUIやFlutterではMVで良い、という意見をよく目にします。 VがMを購読Vがビジネスロジックの起動を依頼という構造です。この構造、どこかで見たと思いませんか?そう、MVCです。AppleのMVCはCがMとVの仲立ちをするのですが、非AppleのMVCでは上記のような構造になっています。