WebアプリでMVCを使う理由ってなに？

それ、えせMVCじゃないの？

くそすれに2

Webアプリ作るのはすげー面倒だから

人的工数を計上するための分業化の産物。
おかげでロクなもんが出来てきやしねぇ。

unit testが適用しやすいから

確かにMVCをWebプログラムに適用するのは無茶といえる

unit testかー。そんなことに無駄な時間を費やす人って多いよね。

使いたいフレームワークがMVCだから

unit testが無駄とか、程度が分かるね。

unit testが要らない設計が出来ないとか、程度が知れるよね。

unitテストが要らない設計なんて無いよ。

反論したいなら
どこかで論文見つけてきてね。
くだらない話はいらない結論だけでいいから。

テストで得られるのはトラブったときに"このコードは原因じゃない"という安心感。

>>1
複数人数でやるとき意思疎通がしやすい
（ドキュメントを読んでもらえば説明をいちいちしなくていい）
あとバグ、セキュリティホールが出る可能性が減る

まぁこれはフレームワークの利点であってMVCである必要はないかもしれんが

>>11
敗北宣言ですね

>>13
反論はどうした？ｗ

俺のサイトもユニットテストが要らない仕組みを導入してる。
意外と知られてないのか、頭が固いのか、2ちゃんのレベルが低いのか、はたして？

突如発生した、ユニットテストが要らない仕組み。
その詳細は、謎に包まれている。

完

今朝、昨晩の修正で生じたエラーをBaiduSpaiderが通知してくれてたｗ
ユーザーやクライアントに知られる前にこそっと修正。
ユニットテストを書かないとダメだなんて、単に頭が硬いだけなんじゃないかな？
もっと発想を柔軟にしてみて！

馬鹿の相手はする価値がない

馬鹿っていうのは>>17

そうですか？自分は非常に興味があります。
もし本当にユニットテストを書かなくて済む実装方法があるなら教えて欲しいです。
自分も業務でユニットテスト書かされてますが、正直バカバカしい作業でうんざりです。

馬鹿がレスしたでしょ？
ユニットテストが必要ない＝BaiduSpaiderだってｗ

>>5だが、変なのが絡んできたと思って見てたら
Baiduspiderがテストツールときたもんだ。安心したよ。

まあ、unit testが不要ではなくて不可能な設計なら
むかぁーしのCOBOLerとかよくやりそうだけどね。

>>21
知らんことに口出すな。

COBOLってのは基本バッチ処理だから
逆にテストが簡単なんだよ。

入力データがあって、処理行なって、
出力データが生成されるだけだからな。

>>22
テストが簡単なんだというのはごもっともなんだけど、
入力データ食わせて出力データが出てくる一連の処理を流して
テストしたと言ってもそれはunit testではない。

それに気づかないような連中が、
unit test不可能な設計をしてくると言ってるんだ。

>>23
入力データを食わせて出力データを出す処理を
しているのが、一つのユニットであれば、
そのテストはユニットテストだよ。

>>24
神クラスに対して自分はまともなユニットテストはできそうにないわ。

COBOLerとか言っちゃって気に触ったのかもしれないけど、
普段からやってる設計見なおしたほうが良いよ。

神クラス？

一体お前は誰と戦っているんだ？
それが前提の話なんかしてねーだろ。

>>26
入力と出力、処理も含めて一手に引き受ける神クラスを作らないと
unit testの対象にできないんだが。

なんか全然別の世界の人と話してるようだ・・・

>>27
お前が変だよ。

他の人もお前のレスで馬鹿がお前って気づいたので、
君のレスはもう不要。

変でも馬鹿でも構わないけど、
unit testの定義くらい理解しておこう。
おそらくそっちの世界では不要だろうしこの話は終わりで。
（BaiduSpaiderテストはまだ興味あるからちょっともったいないが）

MVCの話をしよう。

modelの存在感のなさ(笑)
ユーザーの相手はView
ロジックはControllerがするけど…

>>27
神クラスを作らないとunit testの対象にできない？

なにそれ、馬鹿なの？

1unit=1classとしたら、多機能なクラスを用意しないとダメだろうね。

神クラス作る前提が馬鹿だと気づけよ。

えせMVCについてはまずここらへん読んでからにしようぜ

ttp://satoshi.blogs.com/life/2009/10/rails_mvc.html
ttp://d.hatena.ne.jp/p4life/20091014/1255532618

modelの存在感の無さ　＝　ActiveRecordの薄っぺらい偽Model
ってことだよね。

自分も分厚いController作ってしまったことがあって、今でも反省。

原理主義者ってどこにでもいるよね。
自分だけが唯一絶対に正しいと思っている。

さすがに単体テストの定義が怪しいのはマズイのでは？
そのうち画面1枚を1ユニットとか言い出すぞ。

早く >>17 戻ってこねーかな・・・

俺も気になるね

クラスを使いこなせる人間なんて一握りなのに、
その一握りしかうまく作れないＭＶＣって使えないって結論になるよね。
凡人でもうまく作れるような技法を誰か開発してくれんかのう。

ぶっちゃけ、Mっていらなくね？

>>40
fat modelが理想なんです

おい早くBaiduSpaiderテスター出てこいや！！

>>39
別の話だけど、俺も凡人にも
うまく演奏できるピアノがほしいと思う
で、プロになって商売するんだ

デザパタ語って構造にこだわる原理主義者達、はてなにいそうな人達、なんというか触るとヌルッとしてそう

○○にこだわる原理主義者達、はてなにいそうな人達、なんというか触るとヌルッとしてそう

汎用的に使えますから、○に適当な言葉でも入れてください。
意味が無い文章ですねｗ

>>45
はてなの所はそのままでいいんだw

>>46
もちろん入れ替えていいよｗ

中身が無い文章は、単語を用意に入れ替えられる。
見事に当てはまったので、これは中身が無い文章であるということ。

中身が無い文章は、他の場所の単語も容易に入れ替えられる。

>>47
ダジャレの解説とかしてそうだなお前…

○○にこだわる○○主義者達、○○にいそうな人達、なんというか触ると○○としてそう

>>47
単語を容易に入れ替えられるような文章から、
相手の言いたいことを読み取れず中身がないように感じてしまうあなたは、
コミュニケーション能力が大きく欠落しています。

○○を否定したのなら、その後の文章は○○にたいしての言葉が書かれているもの
お前のさっきの言葉で言えば、デザパタを否定したんだから
その後の文章は、デザパタとはどういうものかってのが書かれているはず。

○○の単語部分だけ変えても同じようになるってことは、
○○ を否定してることにならないんだよ。

その人アタイじゃないよ…

日本語の揚げ足取りは興味ない

BaiduSpiderのテスト手法だけが気になるんだ！

確かに気になる

アなら真名さ

俺のところは

Model…DBの構造定義、O/Rマッピング
View…HTML出力担当
Service…専らDBの操作（CRUD)担当
Controller…HTTPリクエスト処理担当

のMVSCだな

みんなモデルの意味を間違ってんじゃないかなぁ？

ModelでO/Rマッパーを操作するけど
ModelでO/Rマッパーを定義したらいかんのだよ。

それ、モデルの意味が間違ってんなぁ

ORMのないFWはモデルがいらんのか？

じゃぁ、ZFはモデルが要らないなぁ

データベースを使わないシステムだってあるしな。
モデルにO/Rマッパーを密結合するから
モデルが太るわけで。

モデルがマッパーを操作したりマッパーと密結合したりしてるわけじゃないだろ
マッパーが生成したオブジェクトを操作したりしてるだけで

で、マッパーが生成したオブジェクトがモデルじゃなければ何なんだ、って話じゃね

ん？

まずモデル、ここにロジックのすべてが入るべき。

そしてモデルには、ロジックは入るがO/Rマッパーを使っても
使わなくても成り立つようにするべき。

必然的にロジックとO/Rマッパーは分離させるべきという結論になる。

>>63
日本語がおかしくね？もっと冷静になってまとめてから再度書き込んでね。

>>64
＞まずモデル、ここにロジックのすべてが入るべき。

その理屈だと、viewにロジックを書いてはいけないってこと？controllerにも？
viewやcontrollerにロジックを書いた方がプログラムが読みやすくなっても、Model原理主義を貫けってこと？

>>64
＞必然的にロジックとO/Rマッパーは分離させるべきという結論になる。

普通は、そりゃ、そうだろ？
特定のWebアプリのロジックが汎用化される訳がないわけで。
だから、ORMのベースがあって、それを派生させて、Webアプリ固有のORMにカスタマイズしてコントローラに書くロジックを減らしなさい、って思想がsymfonyとかにはあるわけで。

まぁ、そこまでORMを使い倒してる人は滅多にいないけど。

仮にデータベースを使わないでファイルのみを使う
モデルだけで構成されているとして、

「Webアプリ固有のORMにカスタマイズ」とは
どういうこと？

is-a関係、has-a関係ってわかってるかな？
モデル is a ORM ですか？ 違うでしょう？

モデルがORMを継承するのはおかしいんだよ。

>>68
> モデル is a ORM ですか？ 違うでしょう？
>
> モデルがORMを継承するのはおかしいんだよ。

誰がそんな話をしてるんだ？
どこを読んでそう思ったんだ？

話を元に戻すと、Modelの定義はなんだ？
あるのか？ないのか？「ロジックを書くところがモデル」っていう稚拙な回答で終了していいのか？

MVCはもともとGUIアプリのための設計。
それをウェブに持ち込んだからおかしくなった。

本来はViewからModelを参照したり、ModelからViewにイベント
通知したりするものだが（Ajaxがでるまで）ウェブでは実装できなかった。

だからウェブアプリで言うMVCは本来のMVCではない。
それを理解しているところはMVC2と言ったりしているが本来のMVCとは違うもの

つまり、MVCにおけるモデルの定義は簡単だが、それはウェブアプリのモデルにあてはまらない。
ウェブアプリのモデルはどうあるべきか、その答えは色々あるが共通しているのはビジネスロジックを書く場所。
理想的には何も継承しないPlain Objectで作るべき（JavaでいうPOJO）

ウェブ特有のデータ（セッションやクッキー） や データストレージ（RDMBSやキーバリューストア）に
依存しないように書くことで、フレームワークに依存しない寿命が長いシステムを作ることが可能になる。

残念なことに今のフレームワークはモデルと呼ばれるものがO/Rマッパーに密結合しているものが多い。
これだとフレームワークを変更することが出来ない。

フレームワークは便利だから使うべきだが、肝心のビジネスロジックはフレームワークに依存してはならない。

まとめると、
ウェブアプリには「ビジネスロジックを書く部分」がある。これはフレームワークに依存しないPlain Object。
モデルとは、ビジネスロジックにO/Rマッパーを密結合させてGUIアプリのMVCの名前を借りた、意味不明な物。

>>69
> 誰がそんな話をしてるんだ？

>>67
> だから、ORMのベースがあって、それを派生させて、Webアプリ固有のORMにカスタマイズしてしてコントローラに書くロジックを減らしなさい

正しくは、Webアプリ固有のロジック層を作って、（当たり前だがコントローラではない）
ORMはそのロジック層から使うもの。ORMのベースを派生させる必要はない。

ORMのベースを派生して作ったものはORMに依存してしまう。
ORMを派生して作ったものは、最小限（単純な読み書き程度）に抑えるべき。

>>70
おー。やっとまともに話ができる奴が出てきたじゃないか。

まぁ面倒くさいから、結論がでたのでまとめると、細かいところを端折れば、WebアプリにMVCなんて無理なんだよ。

＞フレームワークは便利だから使うべきだが、肝心のビジネスロジックはフレームワークに依存してはならない。

そんな面倒なことしてる？
現実問題としてはフレームワークに依存するから開発が楽なんじゃない？

ビジネスロジックはフレームワークに依存しないだろ
ビジネスロジック以外をまとめて面倒みるのがフレームワークの本質なんだから

モデルについても語っておくか。
GUIアプリのMVCのモデルではなく
ウェブアプリのモデル。

そのモデルという名前のせいかオブジェクト指向バンザイな発想のせいか、
ナンセンスなことに、データベース全体を一つにモデリングしようとしている。
1テーブルが1クラスになって、そのクラス同士を1対1や、1対多などのリレーションでつなげて
巨大なデータの塊を作ろうとしている。
そのせいでクラスとしてはわかれているけれどクラス間の依存関係がきつすぎて関係を把握できなくなってしまっている。

もうね、お疲れさん（笑）というしか無いよ。
そんなのやっても疲れるだけでしょ。

昔から言われてるように、データの寿命は長いけど、ロジックの寿命は短い。
寿命が違うものを一つに合わせるなと。

オブジェクト指向はシステムの構造を作ったり、高機能な値（オブジェクト）を作るために使うけれども
データ自体はオブジェクト指向の発想で作らないほうがいい。適材適所ってやつだ。
寿命の長いデータはロジックを含まない単なるデータとして保存しておき、
ロジック部分でそのデータを読み書きする。

>>75
> ビジネスロジックはフレームワークに依存しないだろ
> ビジネスロジック以外をまとめて面倒みるのがフレームワークの本質なんだから

んじゃ、symfonyで作った掲示板をZendに移植してみてよ。
そこまで言うならサンプルをアップしてみてくれ。

>>76-77

なんか雲行きが怪しくなってきたなぁ。
君の言ってるのはビジネスロジックであって、モデルの原理原則ではないなぁ。
そもそも、その理論では、なぜ「モデル」と名乗っているのか説明できないしさ。

>>78
サンプル作るの面倒だろｗ
そんな面倒なことやる気しないし、
それで出来ないじゃないかと言われるのは心外だな。

まず君がサンプル作ってくれ。
それをベースとしようじゃないか。

>>79
> なぜ「モデル」と名乗っているのか説明できないしさ。
そもそもモデルと名乗るのが間違いだった。
最初にモデルと名乗ったバカが悪い

>>80
> >>78　
> まず君がサンプル作ってくれ。
> それをベースとしようじゃないか。

いや、俺には作れない。
なぜなら、ビジネスロジックをフレームワークから分断することはできないから。
全くできないわけではないが、それではフレームワークを使う意味がなくなってしまう。

> >>79　
> > なぜ「モデル」と名乗っているのか説明できないしさ。
> そもそもモデルと名乗るのが間違いだった。
> 最初にモデルと名乗ったバカが悪い

いや違うんだな。まだ君が、モデルはロジックを書く場所。って程度の理解しか持ってないだけなんだよ。
モデルって名前の由来はある。

viewって昔はHTMLだったよな。JSPとか。
いつのまにViewが単体でクラスになったんだ。

>>81
モデルって名前の由来はある。
で終わらないで、最後まで書いてください。

とりあえずこのスレにMVCを理解している人が一人もいないことは分かった

お前はわかるのか？
なら説明しようね。

1人もいないんだから誰も説明できないことくらい理解しろよ。

それじゃどんな説明受けても理解は無理だろ。

「一人もいない」といった本人は自分のことだから
自分が理解していないことは確定することになる。

でも他人が理解しているかどうかは判断できない。
なぜなら、言った本人は理解していないのだから
書いてある内容が正しいか間違いかは判断できない。

>>86
このスレ以外の知人にも聞いてもらうから説明よろしく

できないなら批判しかできない無能なカスと決定するよ

WebにMVCは無理なんだよ

はい説明できないカス登場

こんな過疎板で書いても仕方ないしな

わかったわかった出来ない朝鮮人お疲れ

>>89
いや、ラクだよ、MVCは。最低限のレイヤリングはできる。

goto 1

以下ループ

え？！それって冗談のつもり！くそつまんない男だな、って女に言われるだろ？

つまんねースレだな

やはりお前らのMVCは間違っている
http://www.slideshare.net/MugeSo/mvc-14469802

「MVCの勘違い」について、もう一度考えてみる
http://at-grandpa.hatenablog.jp/entry/2013/11/01/072636

Facebook の決断：MVCはスケールしない。ならば Flux だ。
http://www.infoq.com/jp/news/2014/05/facebook-mvc-flux

受ける会社大丈夫？
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in tokyo
・「社名　労基」でググると過去の2chスレが出てくる
・転職会議で2.5点

色々、MVCの説明サイト見たけど、理屈よりメリットが抜けてるよな。
メリットは、書くコードが最小限（使い回しが楽）、見て解り易いと言うこと。
問題は、見て解り易いかどうかと言うこと。
大きく分けて、お手本原理主義と使い勝手原理主義がいるが、どっちの思想かを理解しないと理解に苦しむ。
お手本原理主義のコードは、簡単な手続きは理解し易い反面、オーバーヘッドが大きく、お手本に無い場合は、急に使い勝手原理主義になる。
使い勝手原理主義は、最初は解り辛いが、ある程度弄ると、癖が解るので先読みし易く、殆どの場合、php自体を理解している人が書いている。

目的は、工数の削減と、見て解り易いと言うことなので、その辺りを念頭に書けば、きっと君の思いは伝わると思う。

webアプリだからMVCで作っても結局のところ
login1
login2
login3
みたいな糞派生が出てきてわけわかめになって
しかもlogin1はex_login1から読まれていて下手にいじれないというジレンマに陥る
そして俺は何も考えずにlogin4というクラスを作るのであった。

>>102
最初に作った奴がダメだとlogin4作った方が早いよな。
そして、何年か後に、login4が基本クラスになっているのを見るのが、プログラマ名利に尽きる。

☆ 日本を、再興させましょう。☆
総務省の、『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

私がMVCフレームワークをもはや使わない理由
https://www.infoq.com/jp/articles/no-more-mvc-frameworks

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』 というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

AYZJP53MII

ﾌﾟﾌｧｰ(￣△￣）y─┛~~~~~