回答編集履歴
2
補足しました
test
CHANGED
|
@@ -13,5 +13,5 @@
|
|
|
13
13
|
|
|
14
14
|
ただ、Androidのviewはライフサイクルが独特で永続データモデルではないデータを画面の回転などによって破棄されるので、結局viewModelを介さないと行けない気が？します。
|
|
15
15
|
そうなると、viewのデータを保持する(または永続データを取得する)viewmodelとactionのためのviewmodelのふたつが必要になりますね。
|
|
16
|
-
結局は同じmodel(store)のインスタンスを共有することになるのでしょか、
|
|
16
|
+
結局は同じmodel(store)のインスタンスを共有することになるのでしょか、(補足、若干予想はしていましたがstoreはシングルトンで行うようですね、まあactionはviewから必ずしも発行される訳では無いみたいなのでほかの回避策もありそうですがね)
|
|
17
17
|
関心事の分離としてはアリなのかもしれないが
|
1
補足
test
CHANGED
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
actionがDB更新のためのエントリポイントでdispatcherがDBを更新するためのビジネスロジック(viewModel相当)
|
|
10
10
|
|
|
11
11
|
|
|
12
|
-
アーキテクチャの面でいえばMVVMではmodelとviewModelが双方向データバインディング、viewとviewModelが双方向データバインディングをしていたデータモデルが直接viewとmodelに相当する部分がデータバインディングすることで、フローが明確という事な気がします。
|
|
12
|
+
アーキテクチャの面でいえばMVVMではmodelとviewModelが双方向データバインディング、viewとviewModelが双方向データバインディングをしていたデータモデルが直接viewとmodelに相当する部分がデータバインディングすることで、フローが明確(依存関係が単純)という事な気がします。
|
|
13
13
|
|
|
14
14
|
ただ、Androidのviewはライフサイクルが独特で永続データモデルではないデータを画面の回転などによって破棄されるので、結局viewModelを介さないと行けない気が？します。
|
|
15
15
|
そうなると、viewのデータを保持する(または永続データを取得する)viewmodelとactionのためのviewmodelのふたつが必要になりますね。
|