MVC ってこういうこと？(1) -前説-【閃光的網站・弛緩複合体 -Review Division-】
前回、MVC について、View を「ユーザからの入力を受け持つもの（以下「入力用 View」）」と「Model からのデータを表示するもの（以下「出力用 View」）」の二つに分けて考えると理解しやすくなるんではないか、ということを書きました。 入力用 View は Controller だよ、というご意見もあるようですが、取りあえず、View に所属するものとして、上記の考え方に基づき、コードを組んでみます。 私の考える MVC 模式図 前回示した図を再掲します。 黒い矢印に注目してみましょう（話を簡単にするために、灰色の矢印は無いものとして扱います）。 ユーザは入力用 View にデータを入力 入力用 View は、それを Controller に通知 Controller はそれに基づいて、Model に状態変更を要求 Model はそれによって状態を変え、出力用 View に通知
【雑記】 そろそろMVCモデルについて一言いっておくか
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
[tech]GUI-MVCとWeb-MVCの違い - yojikのlog
一部でMVC議論が流行っていたので、自分のためにSmalltalk由来のMVC(以下、一般化してGUI-MVCと呼びます)はWeb-MVCとどう違うか? という点についてまとめて見ました。突っ込みは歓迎。 あと本稿ではドメインモデル貧血症批判とかは全く盛り込まない。それは少し違うレイヤーの話なんです。 0. VCは大抵の場合、緊密に結びついたペアである GUI-MVCではView-Controller(以下VCペア)は不可分のペアだとされています。情報の入力(および制御)と出力ですから、お互い強く依存するのはあたりまえですね。MicrosoftのMFCとかJavaのSwingではVCはひとつのコンポーネントとして扱っています(Document-Viewパターンとも呼ばれます) ただ、この点についてはWeb-MVCでもそんなに変わらないかも。 1. GUI-MVCのView-Controll
![[tech]GUI-MVCとWeb-MVCの違い - yojikのlog](https://cdn-ak-scissors.b.st-hatena.com/image/square/b01b0c66c2194b2606fbb5505652ff3db80d0cdf/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729901763%2F12704830469097198255%2F1365590825)
MVCの議論で思い出したこととか | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー たまにPython自体の技術コンサルみたいなことを頼まれることがある。プロダクトのコードを読ませてもらって，改善点を指摘したりするようなことをやる。 ただ，純粋にPythonにかかわるアドバイスって最初のうちだけで終わってしまい(Pythonは覚えること少ないからね)，だんだんと設計みたいな部分に切り込んでゆくことになる。フレームワークを使ったコードで本当によく見かけるのが「分厚いコントローラに薄いモデル」みたいな設計。もっと進んで「分厚いテンプレート(ビュー?)に薄いコントローラとモデル」というのもたまにあるんだけどあまりない，かな。 で，そういう場合は「テスト」を軸にして，設計上コ
MVC、お前もか - みねこあ
MVC とは、もともとの出自は Smalltalk で、対話型のアプリケーションを作成するためのアーキテクチャのことでした。 Smalltalk なんて知らない人多いでしょうに、普通のプログラミングの話題でこうも顔をピョコピョコ出すのが、なんというか、憂いヤツです。そんな何かと気になるアイツこと、Smalltalk の MVC について、抜群にわかりやすいこちらの梅沢さんの記事をおすすめしておきます。 Happy Squeaking!! -オブジェクト指向再入門- [第五回：デザインパターン事始め] さて、こちらから引用して、MVC の M、V、C がそれぞれどんなモノかというと、 処理を受け持つ部分は、Modelと呼ばれます。アプリケーションで必要となる実際のデータを保持しており、業務に特化した処理を実行します。(中略) Modelの状態を表示する部分はViewになります。ビットマップデ
MVCのMんところ - 売り切れました
うーん はっきりいって、ロジックをModelに書こうがControllerに書こうが、整合性の考慮漏れは、どうしても出てきます。Modelに書いたからといって、Controllerに書いていたときの考慮漏れが自動的に解決することはないのです。 えせMVCについてそろそろ一言言っておくか - yvsu pron. yas これは、あるオブジェクトであるModelが単体ではシステム状態の整合性を保証できないように設計されているという事であって、スレッドセーフではないメソッドと同様に、只単に「あまり良くない設計である」というだけの事じゃないだろうか？ なので、本人も Serviceは永続化されないModelなので、カテゴリはModelです。 えせMVCについてそろそろ一言言っておくか - yvsu pron. yas と、一連のModel利用をServiceという形でwrapしてるんじゃないかと
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
高密度小池 ／ オブジェクト指向とか MVC とか分からなくてもいいならその方がいいよね
オブジェクト指向とか MVC とか分からなくてもいいならその方がいいよね 分からなくてもアプリケーション作れるなら、という意味です。 オブジェクト指向とか MVC とか理解してなくてもアプリケーション作れる仕組みがあるならその方が絶対いい。 Ruby や Java 使ってアプリケーション作るときは脳内にメモリマップを展開する必要はないし、それは素晴しいことだ。オブジェクト指向や MVC を理解しなくてもいいならそれはもっと素晴しいことだろう。 機械は人間の能力を補完するものだから、人間に対して機械にあわせろとか命じるんじゃなくて、機械を進歩させる方がいい。機械を進歩させればその恩恵はあまねく広がるんだから、世界のためにもなる。 まとめれば、身近な、自分の仕事の問題を解決したいなら、周囲の人間を教育するなり、優秀なエンジニアのみを雇うなりすればいいだろう。 世界を変えたいなら M
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
BTS Develop(仮) » PHPとMVCモデル
<愚痴> 今回の仕事で痛感したのは、単体テスト(UnitTest)を活用してないプロジェクトは全然駄目ということですね。品質に理解があるようでいて理解/実践がないし、設計、レビューを繰り返したとしても正常に動作するあるいは作成可能であるかの保障がありません。 そうなると「SIer＞下請け」ヒエラルキーの元で、割を食ってしまうのは下請けのプログラマです。単体試験の工費を貰えず、単体試験を省けば、不具合/障害の責任はプログラマにある。また、単体試験を行えばスケジュールに合わない。余計なことをやっているとみられる。時間を削られれば学習の時間（次への投資）ができなくなる。じり貧になってしまうのは、下請けの底辺プログラマばかり。 というわけで、今後そういう仕事は請けないことにします。 </愚痴> な訳で、インストールマニアックスでPHPを少し触ったことだし、ASP.NETの開発者よりもPHPの開発者
Ruby on Railsは「えせMVC」じゃないよー - このブログは証明できない。
Life is beautifulのこのエントリーは「釣り」でしょ？ no title 先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 ということで、MVCの解説をされています。それは、OK。で、Railsが「えせMVC」だという理由。 ActiveRecordそのものはとても便利なもので全く問題はないのだが、問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。 上に述べた通
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails：ITpro
Ruby on Railsをはじめとする最近のWebアプリケーション・フレームワークの多くは，MVCと呼ばれるデザイン・パターンを採用しています。今回は，このMVCパターンの「正体」について考えます。 MVCはGUIを備えたプログラムを設計する際の指針となるデザイン・パターン＊1の一つです。「モデル」（Model），「ビュー」（View），「コントローラ」（Controller）という3つの構成要素の頭文字から命名されました。多くのデザイン・パターンはプログラムの一部のみの構成を決めています。しかし，MVCはアプリケーション全体の構成を決めることが多いため，「アーキテクチャ・パターン」と呼ばれることもあります。 MVCは，元々プログラミング言語Smalltalkにおいて，ウインドウ（GUI）を持つアプリケーションを構築する際の指針として誕生しました。 MVCを発明したのは，当時，米Xero
使わないと損をするModel-View-Controller MVC
1 はじめに SmalltalkのOJTを通して、「Smalltalkへのスムーズな導入」を行うために、いくつかの留意点があることを私は学びました。 ① データとアルゴリズムがパックされたオブジェクト(情報隠蔽) ② オブジェクト間コニュニケーション(メッセージ伝送) ③ クラスとインスタンス関係(メタクラスとクラス関係) ④ クラス階層構造(インヘリタンス機能) ⑤ アルゴリズムをデータとして扱うこと(closure/continuation) ⑥ Model-View-Controller(MVC) ⑦ 依存性(change&update) ⑧ プラガブルの考え方(pluggableMVC) ①〜④までは、オブジェクト指向プログラミングという形で多くの解説書が手に入りますので問題はありません。 ⑤は、LispやPrologを知っておられる方には簡単になじめます。アルゴリズムをデータとし
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
tenjin.web: workshop/mvc
MVC概論 MVCの重要性 アプリケーションのアーキテクチャ、実装手法 設計と実装のノウハウ 目標 処理の分割・依存性整理 変更通知の整理 ソフトウエアアーキテクチャ BCE(Boundary, Control, Entity) 分析・設計手法 →Webではそのまま設計に持ち込める PAC(Presentation, Abstraction, Control) アーキテクチャ、入れ子構造 GUIだけでなく、ソフトウエア設計一般に使えるパターン MVC(Model, View, Controller) デザインパターン マウスとかイベントとか実装のノウハウ その他いろいろ WebアプリとGUIアプリの違い GUIアプリケーションは複雑[絵] データが変化する 変化を通知する Webアプリ DBに永続化データがある プログラムの寿命：一瞬 DBから取ってきたデータは基本的に変わらない 不変(I
クラウドとHTML5にPHPが沈むとき - noopな日々
インフラ・タグ仕様の両面からPHPの存在意義が問われているように思えます。 安価なインフラとの親和性、テンプレート志向、その双璧が意味をなさなくなってきそうです。 クラウドとPHP (特に日本では)PHPはレンタルサーバーで最も利用しやすいプログラミング言語です。また、LAMPによる開発ノウハウが充実していますので、カジュアルな開発者がもっとも手にしやすい言語と言えそうです。 レンタルサーバーでのリソースがクラウドに移行しようとしている現在でも、たとえばGoogle App Engine上でPHPは実行可能で、Amazon S3,EC2へアクセスする機能を提供しているPHPフレームワークもあります。とはいえ、クラウド上での実装を考えると、関数型言語の方が向いているのは明らか。その意味では、Pythonのように関数型に近い言語の方が向いています。 レンタルサーバー上でPHPを使うにしてもそれ
Catalystでロジックをどこに置くかという話 - libnitsuji.so
Catalystをちゃんと勉強しはじめてからずっと頭の片隅にあるけどまだ解決せず。 俺以外にも悩む人はぜったいいるはずだと思っていたけどMLを検索する方法がよくわかんなかったのでいまいち網羅できず。ひとまず、 Catalyst MVCの覚え書き - libnitsuji.so こんな感じだったのだが、今日、 http://www.mail-archive.com/catalyst@lists.rawmode.org/ を見つけたので「logic」で検索！ 興味深いスレッドとして、 [Catalyst] Program the logic [Catalyst] ways to do stuff and why の二つがあったので読んでみた。 実装までは踏み込んでいないのでそれ以前の話だけど。俺の頭の中もまだ実装前なので具体的にどう実装するかはひとまず置いておく。 俺の疑問点とか考えとかを書い
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Separate Model from Catalyst
