タグ

MVCに関するmorishitterのブックマーク (6)

  • Railsのコントローラーの仕事は何か? - Qiita

    誰も読んでいないブログからの転載 最近MVCがどうとかという内容が話題になっていますが、ちょっと乗っかった内容です。 Railsで初心者によく見られる良くないコードは、コントローラーでたくさんの処理を実装してコントローラーの一つのアクションが30行、40行になってしまうことです。それに対して、モデルに適切に処理を移すのが良いんだということを言うんですが、”適切に”って何?じゃー、コントローラーには何を書くのがいいの?っていう質問への僕なりの回答です。 良いメソッドとは? 直接回答する前に、まずは前提の共有から、プログラムにおいて良いメソッドとはどのようなメソッドでしょうか?僕の解は、以下です。 "引数と返り値が最小限になっているメソッドです" (この部分については別途説明が必要な気がしますが、まぁなんとなくご理解いただけるかなと思います。) Railsのコントローラーの仕事? では、Rai

    Railsのコントローラーの仕事は何か? - Qiita
  • JavaScript MVC Style Guide

    Over the years I've come up with a few rules for MVC web apps that have served me well and kept large codebases from descending into chaos. While the terminology may differ, these rules should hold true for most client-side MVC frameworks such as Backbone and Ember. Some frameworks have different naming MVC conventions, and slightly different takes on separating concerns. In this document, control

  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから(あるいは Marionette.js を使ったらから)といって自動的にお前のアプリケーションが MVC になるわけ

    やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • MVCにおけるcontrollerクラスの役割は時代と共に変わって行く | F's Garage

    昔、JavaのフレームワークであるStrutsも出てくる前、MVCモデルにおけるControllerの役割というのは、 「ロジックもデータも見ない現場監督のような役割」 と学んだ。だから昔、ServletではMVCアーキテクチャを学んだ時に、こんなControllerを書いていた。 [とりあえずRequestオブジェクトを受け取る] | [validationロジックに引き渡す。データの中身は見ない] | [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] | [次にロジック処理クラスに渡す。最終的にDBのテーブルとマッピングしたデータはJavaBeansというデータクラスが保持する] | [例外が発生したらエラーView処理クラスに引き渡す。何のエラーかは細かく知らない] | [Viewの生成オブジェクトにJavaBeansを渡す] | [Viewオブジ

    MVCにおけるcontrollerクラスの役割は時代と共に変わって行く | F's Garage
  • 「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ

    お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている!」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中

    「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ
  • 1