数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている！」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
_ WebMVCと設計パターン WebMVC（面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい）というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装（貧血）と最悪のDomain Model実装（鬱血 ）が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど
Web の場合は View と Controller の違いははっきりしてます。 View は html ページとその作成を担当します。 CGI は アドレスとパラメーター(アドレスの ? の後など)を受け取り、処理を行います。 その受け取り部分が Controller です。 Model と View ではなく、なぜ MVC としたのでしょうか ? 『 GoF 本』 では Controller を分ける利点をいくつか挙げられています。 キーボードの応答を変えたり、メニューからの呼び出しに変更するとき、表示方法を変更しなくていい。 入力イベントを無視するといったことをコントローラーのインスタンスの入れ替えで可能。 その他にも "View を入れ替えれば、 PC アプリ、 Web アプリでも使えるように" という理由もあります。 ちょっと無理そうな話ですが、例えば、 PC アプリが次のような
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
13. 開始処理 1. ブラウザがHTMLからDOMを作る 2. AngularJSがDOMを読み込む 3. ng-appで指定されたタグ以下を スコープにセットする 4. コンパイル 5. 動的にDOMを生成する 6. イベント監視して即時でDOMを更新 http://docs.angularjs.org/guide/concepts 詳しくはここ(英語) AngularJS 16. http://angularjs.org/公式サイト: Todoアプリ HTML 1.<div ng-controller="TodoCtrl"> 2. <ul> 3. <li ng-repeat="todo in todos"> 4. <input type="checkbox" ng-model="todo.done"> 5. <span class="done-{{todo.done}}">{{tod
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi O/R MapperとりわけActiveRecordによって、Model/Entityの区別がつかない人ってのが増えたうえに意味不明な思い込みでMVC批判してみたりとかMVACとか言い出してる状況に名前をつけたいな。 広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi Entityとは、システム設計上のデータの一塊としての実体をさしていて、DBのRowとは本質的には無関係。ModelはMVCパターンにおいて、Controllerからeventをうけとり、Viewに修正を通知するインタフェースであり、実装としてビジネスロジック/ドメインを持ってる 広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi 簡単のためにEntity = Row = Modelとして動的言語によっ
どんなに当たり前になった開発手法やプログラム管理方法があっても、新人さんにとってはHello worldから入って行くと思う。インターネットで、「知の高速道路」が整備されたと言っても、意外と古い話を探すのは難しい話で、MVCみたいに当たり前になってしまったことについて、何故そんなものが存在するのか？という考え方を後から肌で感じるのは難しく、そんなことを考えていたら、突然MVCについて書きたくなった。 以下、書いていくがかなりの偏見が入っている気はするので、ぜひ、歴史認識が間違ってたら僕のためにツッコんでくださいませ。 僕がMVCアーキテクチャを知ったのは、JavaのServletを勉強していた時だった。Javaはオブジェクト思考で作られている言語かつ、Webに特化した言語ではないため、クラス間のデータは、インターフェース仕様に基いて秘匿されるのと、テンプレートエンジンは別に存在していたので
あけましておめでとうございます。本年も本ブログをよろしくお願いいたします。 昨年はいくつかのブログ記事を書かせていただきましたが、中でも以下の2つがよくアクセスされているようです。今年もこのような基礎知識や試行錯誤ネタを中心に書いていこうと思っていますので、よろしくお願いいたします。お気づきの点があれば、はてブやコメント等でお知らせいただけますと幸いです。 ぼくがかんがえたさいきょうのgitとMavenとJenkinsを使った開発 新人に話したJUnitのための知識とTips さて、本日は現在私が取り組んでいるプロジェクトで採用され、それなりに成果を上げていると思われる「Mavenサブモジュールによるレイヤ間依存管理」についてお話します。 Mavenの「モジュール」とは モジュールはMavenが持つ機能の1つで、複数のモジュールによってひとつのプロジェクトを構築することができます。ここで言
JAX-RS is arguably the de-facto standard for creating RESTful web services in Java. Most JAX-RS providers have a way to implement a de-coupled MVC paradigm; much like Spring MVC. This BLOG will demonstrate how Jersey JAX-RS can be used as an MVC web framework and will spend some time discussing the difference between Jersey MVC and Spring MVC. As part of the investigation, the Flight Application t
WebアプリにおけるMVC考察。 （Ajaxではない）CGIアプリでは、Viewの部分がHTMLを出力するだけで、描画そのものはブラウザが全部やってくれていた。 ModelがHTMLを生成していると、ブラウザがViewといっても良いかもしれない。 しかしAjax環境では、XMLHttpRequest（以後XHR）による通信が必要になるため、CGIアプリがHTMLを出力したら終わりというわけではなく、受信したHTMLデータをブラウザに渡す処理（JavaScript）が必要になる。 Viewの一部をXHRに置き換えたものが、フレームワークとして数多く発表されている。 サーバーサイドのViewでHTMLにしておくと、クライアントサイドでは受け取ったraw dataをそのままブラウザに渡し、innerHTMLに代入するだけで描画が終わる。 そのためViewの受信部分は以下のような1行で終わってしま
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く