クライアントサイドの実装におけるModelとは何か
先に結論
データやロジックに関するアーキテクチャではない
先人たち
@jarredsumner: @SimonDragsbaek @rickhanlonii @dan_abramov Before React, the “best practice” was Model, View, and Controller. You had three big files for every page. Teams argued about “fat model skinny controller”. Due to “separation of concerns”, sharing parts of pages meant you needed to refactor the controller, model, and view. @rickhanlonii: @dan_abramov It’s like original React changed how we thought about separation of concerns from separating technologies to separating components, and now it’s doing the same for separating the stack. It’s just components all the way down. 世の中の90%のアプリは、よほど小規模なものでもない限りはこの「ActiveRecordパターンの再発明」という罠をダイナミックに踏みつけて爆死します。 簡単な原則を守れば複雑なアーキテクチャはいらない。
ただしスケールするクライアントアプリの設計をするのであればCRUDを基準にした "Model" というクラスは作るべきではない。 Modelはモジュールの総体として浮かび上がるものである。
koushisa.iconの類似スクラップ
---
クライアントサイドの実装におけるモデルという概念は何なのか？ 考察
ロジックはとりあえずモデルに置いとけばええやんみたいな感覚で全ての処理が配置されがち RailsのFatModelなどはいい例
もっと具体的な名前にしたほうがよいのでは
Modelに全てのデータを乗せるとデータ構造が少しでも複雑になると責務が肥大化して破綻する TODOアプリならいざ知らず、現実世界のプロダクトでは考えることが山ほどある
自身をsubscribeしているViewへの更新通知
キャッシュや通知
全てのロジックをModelに閉じ込めると
気づいた時には時既に遅しで誰も手を出せなくなる
Viewとオブジェクトの結びつきの理解が難しい
オブジェクトにViewのための処理が書かれはじめてデータフローが破綻する
MVVM時代は特にこのような問題が発生しがちだった 収束
データ、ロジックはまた別の思想が必要となる
コンポーネントを中心に組み立てることを前提としつつ、データ、ロジックは関心や振る舞いの単位で分ける
Reactの哲学ではデータとロジックを近づける傾向にあり、その最小単位はコンポーネントである 技術の螺旋から見ると現代的なアーキテクチャは以下のエッセンスを意識するとシステム全体で高凝集な設計を目指せる