サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
varmil.hateblo.jp
MongoDBのインデックス このドキュメントはMongoDB 2.6を前提にしています インデックスとは 例えば1億件のドキュメントからnameがwatanabeであるドキュメントを検索することを考えます インデックスが無ければ 全てのドキュメントの中を一つづつ見なければnameがwatanabeのドキュメントを見つけることができません。 辞書で単語を1ページ目から順番に探すイメージです 処理時間はドキュメント数に比例します。いわるゆ O(N) です インデックスがあると nameがwatanabeであるドキュメントの物理的な位置を既に知っているため、すぐにドキュメントを見つけられます 辞書の索引を引くイメージです 処理時間はドキュメント数に比例しません。いわゆる O(1) です インデックスはDBのパフォーマンスチューニングで、最も基本で最も重要!!! MongoDBとて例外ではない!
なぜこの設計になっているのか なぜAction Creatorsがあるのか MVCでいうCにあたる(dispatcherも含めて)(Model = Store, V = Component)のだろうが、その役割そのもの つまり、Viewとロジックの 疎結合 を保つために必要。容易に取り替えられるような Interface となる。 依存関係を図に書いてみると分かりやすいかも。Actionsがない場合、Component - Store間の依存性が凄いことになる。 なぜConstantsがあるのか イベント駆動で書いていると、イベント名(string)がグローバルっぽい感じになって管理しづらい。 それを一箇所にまとめるために必要だった。(個人的解釈) Action Creatorsから、イベントdispatchするのはなぜ dispatcherがあるおかげで、Store間の依存関係を管理でき
React.jsでだるいところ 末端のコンポーネントから最上位コンポーネントへイベントを何度も伝播させる必要がある(これはMVC設計なら必ず起こりうる) 最上位コンポーネントのみが持っているstateを末端コンポーネントへ向かって何度も伝える必要がある。 React をアプリ全体に適用する場合でも、コンポーネントの階層が深いと同じ問題があります。状態を持つ上位のコンポーネントとその状態が欲しい末端のコンポーネントの間で、中間コンポーネントが自分と関係ないデータやイベントハンドラを下に伝える必要が出てくるからです。なので、結局コンポーネントの階層構造外に状態を持ちたくなります。 React.js 実戦投入への道 この問題への解決策がActionsとDispatcher C#実装への応用案1 機能毎(対応するController単位とか。Controllerを置き換えるもの)で、 Action
このページを最初にブックマークしてみませんか?
『varmil.hateblo.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く