ライブラリを使わずにMV*の話(iOS)〜MVC, MVP, MVVM〜
話すこと アプリの責務の分け方 Model アプリ内で扱う状態・値を持つ Modelの外から指示を受け処理を行う 状態・値の変化をModelの外へ間接的に知らせる View/Whatever 画面の構築/表示 ユーザー操作の受付 アクションを定義する アクションの結果/途中経過を受け取る 内部表現を視覚表現へ変換する MV* の種類 View/Whatever間での仕事の分け方は複数ある (Model-View-Whatever 間の接続の仕方も複数ある) 分けた後のクラス連結の仕方 Commandパターン(直接指示する) Observerパターン(間接的に通知する) 対象読者 Fatなクラスを作りがちで困っている人 責務の分け方にはどういうものがあるのか知りたい人 分け方と分けた後のクラス間の接続がわからず困っている人 話さないこと ■ MV*の歴史的経緯 理由: どれが正史か判断する手
最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
2018年Vue.jsとVuexを使ってる人には知って欲しいFluxデザインパターンとViewModelとの組み合わせ - Qiita
前置き フロントエンドを開発する場合、なんとなくでFluxデザインパターンを実装したライブラリを使うことが良くあります。 それらなんとなく使う人の動機は大抵 なんかイケてる感があるのでとりあえず使いたい でしょう。 そのせいでFluxデザインパターンを正しく理解しないで使った場合には当然のように、データが単方向に流れて幸せになるのではなく、無駄にでかい機構で出来たグローバル変数を使って、著しく生産性を下げ、技術的負債は溜まっていくでしょう。 今回はそれらの悩みを感じ始めた方に対しての Fluxデザインパターン を正しく理解するのを目的とします。 また、その上でVue.jsとVuexの結合パターンの1つを提案出来たらと思います。 ※ 私はVue.jsとVuexでアプリを開発しています。React Reduxで業務をしたことがありません。それを前提とした上での話になります。 ※ 2018年6月
RxSwift+CleanArchitectureで構成をキレイにしよう - Qiita
はじめに アプリケーションを開発しリリースした際に、当初は問題なくても時が経つにつれて綻びが出てきます。 仕様変更や機能追加やリファクタリングができない(後回しにしたまま)、開発に携わる人の理解や嗜好による統一感の喪失などなど。 そうするとこんなことが起きることもしばしば。 ViewControllerの肥大化 責任範囲がぶれたクラスの誕生 Model/Helper/Libraryが人の解釈に依存するディレクトリ・ファイルの散見 ViewModelとModelの扱いがごっちゃになっている こうなるとどんどん作りが複雑化し、気が付くと負の遺産が出来上がっています。 メンバーの理解度を上げる、チーム内でルールを決めるという解決する手もあるのですが できればもう少し役割がはっきりしていて、共通認識持ちやすいアーキテクチャがないかなーと思っていてたところ…それはありました。 それがCleanArc
やさしくわかるMVVM // Speaker Deck
iOSDC 2017 Reject Conference days1の発表資料です
実況中継シリーズ - 複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ - Re.Ra.Ku tech blog
先日行われた builderscon tokyo 2017 にて、「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてきました。この記事では、そのプレゼンテーションの再現を行います。 アバンパート 本日はこういう発表をします。よろしくおねがいします。 普段はメディロムという会社で働いていて、ScalaとJSを主軸に活動しています。PerlとRubyもたしなむ程度には書きます。業務では、業務で使うアプリケーションをブラウザプラットフォーム上に作っています。こういうブログも書いてるんでよかったら読んでください。 あと、何度かweb+DBプレスに特集書かせてもらっていて、とくに左の「データ構造の基礎知識」ってやつは自分で言うけどまじでいい記事なんでまだ読んでないひとはバックナンバー買って読んでください。 さて、複雑なアプリケーションに立ち向かうためのアー
モバイルアプリアーキテクチャ勉強会 - Qiita
public class MainActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Log.d(msg, "The onCreate() event"); } } つまり M-VC iOS も Android も View と Controller がまとめられてる M-VC なコードになる Model, ViewController という関係性 テストがかけない... だから設計談義が盛り上がる アーキテクチャを導入する目的 保守性の高いコード FatController にしない テストのかきやすい構成へ 考え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
