twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基本非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて
先日行われた builderscon tokyo 2017 にて、「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてきました。この記事では、そのプレゼンテーションの再現を行います。 アバンパート 本日はこういう発表をします。よろしくおねがいします。 普段はメディロムという会社で働いていて、ScalaとJSを主軸に活動しています。PerlとRubyもたしなむ程度には書きます。業務では、業務で使うアプリケーションをブラウザプラットフォーム上に作っています。こういうブログも書いてるんでよかったら読んでください。 あと、何度かweb+DBプレスに特集書かせてもらっていて、とくに左の「データ構造の基礎知識」ってやつは自分で言うけどまじでいい記事なんでまだ読んでないひとはバックナンバー買って読んでください。 さて、複雑なアプリケーションに立ち向かうためのアー
MVVMパターンは、GUIのアーキテクチャパターンの一種で、PresentationとDomainの分離（PDS）を目的としたパターンです。MVVMパターンを採用することによって、プラットフォーム依存なUIを実現するプレゼンテーション層をViewとViewModelに書き、その他すべてをModelに書くことによって、「複雑だしプラットフォーム依存でテストしにくいUIのコード」と「アプリケーションの挙動をモデリングしたコード」を分離することができます。 その一方で、MVVMは「モデルはこう設計しましょう」ということについては指針をくれません。これは、言い方を変えれば、MVVMを採用したからといってアプリケーション全体の設計が決まるわけではなく、MVVMは「プレゼンテーションとその他をどうやって分けるか」について指針をくれるだけ、ということです。 ところで、混乱が起きやすいポイントですが、PD
この記事は、2017年3月4日に大阪にて行われたYAPC::Kansaiというカンファレンスで発表した、「Vue.jsで学ぶMVVM 非同期処理 その光と闇」というプレゼンの再現ブログの後編です。前編はこちらですので、前編をまだ読んでない方はぜひそちらからどうぞ。それでははじめます。 Bパート導入 さて、Aパートでは、 無駄にSPAするのはよくない SPAするならGUIのアーキテクチャ・パターンを参考にしよう GUIアプリケーションパータンの中から、MVVMとはどういうパターンなのか ということについて見てきました。Bパートでは、MVVMを採用したプロダクトでわたしが実際にどのような課題にぶち当たり、どのようにその課題に対応してきたかについて見ていきたいと思います。 認証、セッションまわりの話 まずは、実用的なwebアプリケーションには付き物である認証、セキュリティ周りの話から見ていきます
最近はずっとJSでGUIを書くっていうお仕事をやっていて、その中で様々な知見が溜まってきてます。 そのときにひしひしと感じたんだけど、世の中にはさまざまなアプリケーション・アーキテクチャの話が溢れかえっていて、結構混乱を産んでいるように思います。 MVVMだけ見ても、「MVVMで実装しています」って主張しているものがMVVMパターンと違うパターンで実装されていたり、「軽量MVVM」なんて言葉が生まれていたりという状況があって、これはだいぶ混乱が極まっているぞ、と感じる状況です。 また「最近はClean Architectureが熱いらしい！MVVMを捨ててやってみよう！」とか言う発言を目にしたりして、「Clean ArchitectureとMVVMは矛盾しないからMVVMを捨てる必要はないんだよ！」って思ったりもするわけです。 そういう混乱の中にあるひと（それは知見を貯めるまえの自分のこと
2017年3月4日に、大阪にてYAPC::Kansaiというカンファレンスが開催されました。弊社からもわたしがスピーカーとして参加しており、「Vue.jsで学ぶMVVM 非同期処理 その光と闇」という発表をしてまいりました。とても参考になる発表が非常に多く、Perlコミュニティの力を改めて感じました。また、懇親会などでも、たくさんのハッカーと議論や情報交換ができ、大変有意義でした。カンファレンスは議論や情報交換してこそですよね！ というわけで、恒例のプレゼン再現ブログ「実況中継シリーズ」を行います。長くなりすぎるので前半と後半に分けます。本日は前半のみの公開です。 導入 本日はこういう発表をします。よろしくおねがいします。 簡単に自己紹介をさせてください。さいきん会社の名前が変わって、リラクっていう名前だったのがメディロムっていう名前になったんですけど、そこで働いています。言語的にはまあだ
前説 丸山です。Re.Ra.Ku. アドベントカレンダー13日目の記事です。前日はiOSアプリのUIをコードで書いてみる話でした。明日はおそらくScalaの話になると思います。 さて、以前も話題にしましたが、builderscon2016が先日開催されました。チケットは3hでSOLD OUT。プラチナチケットと化した参加権ですが、発表する側ならば実質無料で参加し放題！これはいっそ申し訳ないレベルでは！？ というわけで、せっかく発表したのでその内容をなるべく多くの手段で共有したい。そう思い、今回も実況中継シリーズを弊社テックブログで行います。実況中継シリーズというのは、プレゼンをブログで再現するアレです。なお、実際のプレゼンは動画になってYoutubeにアップロードされております。builderscon公式サイトのセッション詳細ページからもご覧いただけますので、よろしければそちらも合わせてご
ここ何回か、なんちゃって書籍ビューアを題材にした、Xamarin.Formsアプリを紹介してきました。 github.com 今回は、そのコードの解説を試みたいと思います。 今回紹介するコードは、以下の要素が含まれています。 Xamarin.Forms Prism for Xamarin.Forms ReactiveProperty MVVM Pattern Moq ところで皆さんは、MVVMパターンを取り扱った以下のエントリーを読まれたことはあるでしょうか？ ugaya40.hateblo.jp こちらのエントリーの中で以下のようなに書かれています。 ViewModelはModelの影（そしてまたViewはViewModelの影） ModelについてViewModelが行うことは、イベントに対する反応と戻り値のないメソッドの呼び出ししかない事 実はこの二つのことを、今回紹介するアプリケー
GUIアーキテクチャパターンとしてModel View Whateverを採用した際に、Rxのストリームをプレゼンテーション層からモデル層まで一気通貫でつなげてしまうのはアンチパターンである、という話をします。 前提 GUIアーキテクチャパターンにおける Model View Whatever パターン、とくにMVVMに近いパターンを前提とします。いわゆるサーバサイドの「web系MVC」は前提としません。 Model View WhateverパターンとPDS そもそもGUIアプリケーションでModel View Whateverというアーキテクチャパターンを採用する理由として、PDSの実現があります。このあたりの話は詳しくは実況中継シリーズ Vue.jsで実現するMVVMパターン Fluxアーキテクチャとの距離 - Re.Ra.Ku アドベントカレンダー day 13 - Re.Ra.K
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
