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

1nobodyさん2012/06/25(月) 22:58:18.06ID:???
それ、えせMVCじゃないの?

56nobodyさん2013/01/05(土) 03:29:54.86ID:???
俺のところは

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

のMVSCだな

57nobodyさん2013/01/05(土) 10:16:00.81ID:???
みんなモデルの意味を間違ってんじゃないかなぁ?

58nobodyさん2013/01/06(日) 04:58:11.63ID:d/pWw/oN
ModelでO/Rマッパーを操作するけど
ModelでO/Rマッパーを定義したらいかんのだよ。

59nobodyさん2013/01/06(日) 08:28:12.84ID:???
それ、モデルの意味が間違ってんなぁ

60nobodyさん2013/01/06(日) 08:29:07.12ID:???
ORMのないFWはモデルがいらんのか?

61nobodyさん2013/01/06(日) 08:29:58.11ID:???
じゃぁ、ZFはモデルが要らないなぁ

62nobodyさん2013/01/06(日) 08:40:28.78ID:???
データベースを使わないシステムだってあるしな。
モデルにO/Rマッパーを密結合するから
モデルが太るわけで。

63nobodyさん2013/01/06(日) 13:01:06.50ID:???
モデルがマッパーを操作したりマッパーと密結合したりしてるわけじゃないだろ
マッパーが生成したオブジェクトを操作したりしてるだけで

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

64nobodyさん2013/01/06(日) 13:18:24.23ID:???
ん?

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

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

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

65nobodyさん2013/01/06(日) 15:28:21.26ID:???
>>63
日本語がおかしくね?もっと冷静になってまとめてから再度書き込んでね。

66nobodyさん2013/01/06(日) 15:33:21.91ID:???
>>64
>まずモデル、ここにロジックのすべてが入るべき。

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

67nobodyさん2013/01/06(日) 15:38:46.57ID:???
>>64
>必然的にロジックとO/Rマッパーは分離させるべきという結論になる。

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

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

68nobodyさん2013/01/06(日) 17:03:34.03ID:???
仮にデータベースを使わないでファイルのみを使う
モデルだけで構成されているとして、

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

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

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

69nobodyさん2013/01/06(日) 21:26:03.11ID:???
>>68
> モデル is a ORM ですか? 違うでしょう?
>
> モデルがORMを継承するのはおかしいんだよ。

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

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

70nobodyさん2013/01/06(日) 22:01:20.73ID:???
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の名前を借りた、意味不明な物。

71nobodyさん2013/01/06(日) 22:32:51.78ID:???
>>69
> 誰がそんな話をしてるんだ?

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

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

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

72nobodyさん2013/01/07(月) 13:14:47.78ID:???
>>70
おー。やっとまともに話ができる奴が出てきたじゃないか。

73nobodyさん2013/01/07(月) 13:36:28.58ID:???
まぁ面倒くさいから、結論がでたのでまとめると、細かいところを端折れば、WebアプリにMVCなんて無理なんだよ。

74nobodyさん2013/01/07(月) 13:42:47.54ID:???
>フレームワークは便利だから使うべきだが、肝心のビジネスロジックはフレームワークに依存してはならない。

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

75nobodyさん2013/01/07(月) 18:34:00.05ID:???
ビジネスロジックはフレームワークに依存しないだろ
ビジネスロジック以外をまとめて面倒みるのがフレームワークの本質なんだから

76nobodyさん2013/01/08(火) 00:01:08.04ID:???
フルスタックなフレームワークがあるせいで
1つのフレームワークがあって、それがアプリ全体に
結合しているものみたいな感じになってるからなぁ。

フルスタックなフレームワークを細かく分解すると、
まずコントローラフレームワークがある。
このコントローラのフレームワークの役割は、CLIプログラムの
引数解析ライブラリと同じで、ブラウザを使って操作して発生した引数を解釈するもの

次にビューのフレームワーク、いわゆるテンプレートエンジン。
出力したいオブジェクトを特定のテキスト形式に変換して出力するもの。

コントローラのフレームワーク(引数解析)とビューのフレームワーク(出力形式整形)は
明らかにプログラムの中核の処理とは分離されてる。便利なライブラリとして使うが
処理自体は依存しておらず、中核の処理に対して前処理と後処理を行うものでしかない。

あとはモデルというかロジック部分。ロジックでは一般的にファイルやデータベースへアクセスすることになる。
そこでO/Rマッパーなどが利用されるが、ロジックで直接ファイルやデータベースへアクセスするのではなく
間に一層入れてロジックは特定クラスの読み書きメソッドを呼ぶだけにしておくと、物理的なストレージを変更しやすくなる。

図にするとこんな感じ

入力→ ┐
     ├ ビジネスロジック ⇔ 読み書き
出力← ┘

入力、出力、読み書き、はフレームワークを使って便利にする。しかしビジネスロジックはフレームワークに依存させない

77nobodyさん2013/01/08(火) 00:20:34.96ID:???
モデルについても語っておくか。
GUIアプリのMVCのモデルではなく
ウェブアプリのモデル。

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

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

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

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

78nobodyさん2013/01/09(水) 13:35:29.63ID:???
>>75
> ビジネスロジックはフレームワークに依存しないだろ
> ビジネスロジック以外をまとめて面倒みるのがフレームワークの本質なんだから

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

79nobodyさん2013/01/09(水) 14:01:48.63ID:???
>>76-77

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

80nobodyさん2013/01/10(木) 00:36:43.40ID:???
>>78
サンプル作るの面倒だろw
そんな面倒なことやる気しないし、
それで出来ないじゃないかと言われるのは心外だな。

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

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

81nobodyさん2013/01/10(木) 08:43:23.45ID:???
>>80
> >>78 
> まず君がサンプル作ってくれ。
> それをベースとしようじゃないか。

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

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

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

82nobodyさん2013/01/10(木) 19:59:22.41ID:???
viewって昔はHTMLだったよな。JSPとか。
いつのまにViewが単体でクラスになったんだ。

83nobodyさん2013/01/11(金) 01:13:19.36ID:???
>>81
モデルって名前の由来はある。
で終わらないで、最後まで書いてください。

84nobodyさん2013/01/13(日) 11:27:12.10ID:???
とりあえずこのスレにMVCを理解している人が一人もいないことは分かった

85nobodyさん2013/01/13(日) 14:58:41.08ID:???
お前はわかるのか?
なら説明しようね。

86nobodyさん2013/01/13(日) 20:09:33.62ID:???
1人もいないんだから誰も説明できないことくらい理解しろよ。

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

87nobodyさん2013/01/13(日) 21:41:23.94ID:???
「一人もいない」といった本人は自分のことだから
自分が理解していないことは確定することになる。

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

88nobodyさん2013/01/14(月) 08:18:45.08ID:???
>>86
このスレ以外の知人にも聞いてもらうから説明よろしく

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

89nobodyさん2013/01/14(月) 12:18:33.63ID:???
WebにMVCは無理なんだよ

90nobodyさん2013/01/14(月) 12:23:17.76ID:???
はい説明できないカス登場

91nobodyさん2013/01/14(月) 13:04:10.54ID:???
こんな過疎板で書いても仕方ないしな

92nobodyさん2013/01/14(月) 13:19:46.32ID:???
わかったわかった出来ない朝鮮人お疲れ

93nobodyさん2013/01/14(月) 20:06:26.96ID:???
>>89
いや、ラクだよ、MVCは。最低限のレイヤリングはできる。

94nobodyさん2013/01/23(水) 19:23:56.24ID:???
goto 1

以下ループ

95nobodyさん2013/01/24(木) 08:48:04.55ID:???
え?!それって冗談のつもり!くそつまんない男だな、って女に言われるだろ?

96nobodyさん2013/04/17(水) 23:41:05.48ID:???
つまんねースレだな

97nobodyさん2013/11/01(金) 18:03:07.87ID:???
やはりお前らのMVCは間違っている
http://www.slideshare.net/MugeSo/mvc-14469802

98nobodyさん2013/11/01(金) 18:04:41.52ID:???
「MVCの勘違い」について、もう一度考えてみる
http://at-grandpa.hatenablog.jp/entry/2013/11/01/072636

99nobodyさん2014/05/29(木) 22:16:10.29ID:???
Facebook の決断:MVCはスケールしない。ならば Flux だ。
http://www.infoq.com/jp/news/2014/05/facebook-mvc-flux

100nobodyさん2015/10/06(火) 02:15:05.05ID:Z1aqUg5G
受ける会社大丈夫?
下記の条件が全て当てはまる会社にご注意下さい。

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

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

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

102nobodyさん2016/02/19(金) 16:11:57.91ID:???
webアプリだからMVCで作っても結局のところ
login1
login2
login3
みたいな糞派生が出てきてわけわかめになって
しかもlogin1はex_login1から読まれていて下手にいじれないというジレンマに陥る
そして俺は何も考えずにlogin4というクラスを作るのであった。

103nobodyさん2016/02/20(土) 03:20:31.85ID:???
>>102
最初に作った奴がダメだとlogin4作った方が早いよな。
そして、何年か後に、login4が基本クラスになっているのを見るのが、プログラマ名利に尽きる。

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

105nobodyさん2016/06/30(木) 18:31:48.07ID:???
私がMVCフレームワークをもはや使わない理由
https://www.infoq.com/jp/articles/no-more-mvc-frameworks

106nobodyさん2017/12/30(土) 14:52:47.50ID:YhlYw6jg
誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。

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

AYZJP53MII

新着レスの表示
レスを投稿する