iOSDC 2017 Reject Conference days1の発表資料です
こんにちは、ほそ道です。 今回はMV**なフレームワークのひとつであるVue.jsを取り上げてみます。 さて、どこから手をつけたら良いものかと思案にくれた結果、序論や諸注意点をアレコレ展開する前にまずはビシバシと弄って、ヒジョーにシンプルなサンプルをいっぱい作って体にしみ込ませてみるのがイイんじゃないかと思いました。 ボリュームがあるので何回かに分け、今回はビューモデルを生成するパターンをまとめます。 「考えるな、感じろ」の精神でやった後にどう考え学習すべきかや、どう設計すべきかなどの私見は述べられたら良いなと思っております。 ViewModel生成編 ディレクティブ編 [インスタンスメンバ編] (http://qiita.com/setzz/items/ebbfcc3565bcd27f344c) [グローバルメソッド編] (http://qiita.com/setzz/items/8f0
This GitHub project has been archived. Ongoing development on this project can be found in https://github.com/aspnet/AspNetCore. Note: For ASP.NET MVC 5.x, Web API 2.x, and Web Pages 3.x (not ASP.NET Core), see https://github.com/aspnet/AspNetWebStack ASP.NET Core MVC gives you a powerful, patterns-based way to build dynamic websites that enables a clean separation of concerns and gives you full c
![GitHub - aspnet/Mvc: [Archived] ASP.NET Core MVC is a model view controller framework for building dynamic web sites with clean separation of concerns, including the merged MVC, Web API, and Web Pages w/ Razor. Project moved to https://github.com/aspnet/A](https://cdn-ak-scissors.b.st-hatena.com/image/square/94fcb53e54b36070d59b6b3316263c8c46f67c99/height=288;version=1;width=512/https%3A%2F%2Fv17.ery.cc%3A443%2Fhttps%2Fopengraph.githubassets.com%2Ffa92b70d7aa1e98558b6fc91a0bb76b0a6a35657a5982e9a1cb5c94258edf16e%2Faspnet%2FMvc)
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
原文: http://www.martinfowler.com/eaaCatalog/serviceLayer.html by Randy Stafford アプリケーションの境界をサービス層を使って定義する。サービス層は利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる。 解説の全文は『PofEAA』 133 ページを参照。 エンタープライズアプリケーションには、 ストアしているデータと実装しているロジックとの間に 様々なインターフェイスが必要である。 例えば、データローダー、ユーザーインターフェース、統合ゲートウェイなど。 それらは目的は異なるが、データにアクセスしたり、データを操作したり、ビジネスロジックを呼び出したりと、アプリケーションとの相互作用が必要である点で共通している。 Service Layer はアプリケーション境界 [Cockburn PloP]
Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern
When looking beyond the RAD (drag-drop and configure) way of building user interfaces that many tools encourage you are likely to come across three design patterns called Model-View-Controller, Model-View-Presenter and Model-View-ViewModel. My question has three parts to it: What issues do these patterns address? How are they similar? How are they different?
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Free and open-source software portal Ember.js is an open-source JavaScript web framework that utilizes a component-service pattern. It is designed to allow developers to create scalable single-page web applications by incorporating common idioms, best practices, and patterns from other single-page-app ecosystem patterns into the framework.[3] Ember is used on many websites including HashiCorp, Dig
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
Model-View-ViewModel概念図。直線は直接的なAssociationを表し、破線は（例えば）Observer パターンを経た間接的なAssociationを表す。 Model-View-ViewModel (MVVM、モデル・ビュー・ビューモデル) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である[1]。 MVVMはソフトウェアをModel・View・ViewModelの3要素に分割する。プレゼンテーションとドメインを分離し（V-VM / M）また宣言的Viewを分離し状態とマッピングを別にもつ（V / VM）ことでソフトウェアの保守性・開発生産性を向上させる。 Model-View-ViewModelパターンはModel-View-Controller (MVC) パターンの派生であり、特にPresentation Model[2] パターンを直
MVCの典型的な相関図 Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。 MVCはソフトウェアを処理/Model・表示/View・入力伝達/Controllerの3要素に分割し、ソフトウェア内部データをユーザーが直接参照・編集する情報から分離する。プレゼンテーション（View・Controller）とドメイン（Model）を分離しまたユーザー入力（Controller）と表示（View）も分離することでソフトウェアの保守性・開発生産性を向上させる。 1979年: パロアルト研究所にてトリグヴェ・リーンスカウクが考案[1][2]。長い間、Smalltalk-80の実装のみが公開され、MVCに関する公開情報はなかった 1988年: 最初の論文「A Cookbook for Usin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
