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

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

3: nobodyさん 2012/07/02(月) 23:28:53.71 ID:???
Webアプリ作るのはすげー面倒だから

 

4: nobodyさん 2012/07/13(金) 20:48:30.96 ID:???
人的工数を計上するための分業化の産物。
おかげでロクなもんが出来てきやしねぇ。

 

5: nobodyさん 2012/07/22(日) 02:02:56.95 ID:???
unit testが適用しやすいから

 

21: nobodyさん 2012/09/08(土) 00:02:13.42 ID:???

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

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

 

22: nobodyさん 2012/09/08(土) 16:11:03.82 ID:???

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

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

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

 

23: nobodyさん 2012/09/08(土) 21:03:28.39 ID:???

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

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

 

24: nobodyさん 2012/09/08(土) 22:45:26.24 ID:???
>>23
入力データを食わせて出力データを出す処理を
しているのが、一つのユニットであれば、
そのテストはユニットテストだよ。

 

25: nobodyさん 2012/09/09(日) 00:09:56.66 ID:???

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

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

 

6: nobodyさん 2012/08/27(月) 01:29:16.19 ID:???
確かにMVCをWebプログラムに適用するのは無茶といえる

 

7: nobodyさん 2012/08/27(月) 01:50:38.04 ID:???
unit testかー。そんなことに無駄な時間を費やす人って多いよね。

 

8: nobodyさん 2012/08/27(月) 02:04:53.65 ID:???
使いたいフレームワークがMVCだから

 

9: nobodyさん 2012/08/28(火) 22:56:52.74 ID:???
unit testが無駄とか、程度が分かるね。

 

10: nobodyさん 2012/08/30(木) 00:51:11.22 ID:???
unit testが要らない設計が出来ないとか、程度が知れるよね。

 

11: nobodyさん 2012/08/31(金) 21:20:42.70 ID:???

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

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

 

13: nobodyさん 2012/09/02(日) 19:44:32.91 ID:???
>>11
敗北宣言ですね

 

14: nobodyさん 2012/09/02(日) 20:34:14.91 ID:???
>>13
反論はどうした?w

 

12: nobodyさん 2012/09/02(日) 19:10:50.85 ID:7yiRRC3O

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

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

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

 

15: nobodyさん 2012/09/02(日) 22:26:25.18 ID:???
俺のサイトもユニットテストが要らない仕組みを導入してる。
意外と知られてないのか、頭が固いのか、2ちゃんのレベルが低いのか、はたして?

 

16: nobodyさん 2012/09/02(日) 23:20:24.77 ID:???

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

 

17: nobodyさん 2012/09/03(月) 12:15:11.17 ID:???
今朝、昨晩の修正で生じたエラーをBaiduSpaiderが通知してくれてたw
ユーザーやクライアントに知られる前にこそっと修正。
ユニットテストを書かないとダメだなんて、単に頭が硬いだけなんじゃないかな?
もっと発想を柔軟にしてみて!

 

18: nobodyさん 2012/09/03(月) 21:36:33.57 ID:???

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

馬鹿っていうのは>>17

 

37: nobodyさん 2012/09/23(日) 08:55:30.43 ID:???
早く >>17 戻ってこねーかな・・・

 

19: nobodyさん 2012/09/03(月) 21:42:26.22 ID:???
そうですか?自分は非常に興味があります。
もし本当にユニットテストを書かなくて済む実装方法があるなら教えて欲しいです。
自分も業務でユニットテスト書かされてますが、正直バカバカしい作業でうんざりです。

 

20: nobodyさん 2012/09/03(月) 22:17:03.36 ID:???
馬鹿がレスしたでしょ?
ユニットテストが必要ない=BaiduSpaiderだってw

 

26: nobodyさん 2012/09/09(日) 04:02:34.81 ID:???

神クラス?

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

 

27: nobodyさん 2012/09/09(日) 16:18:09.35 ID:???

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

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

 

28: nobodyさん 2012/09/09(日) 23:21:20.71 ID:???

>>27
お前が変だよ。

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

 

31: nobodyさん 2012/09/10(月) 13:48:13.14 ID:???

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

なにそれ、馬鹿なの?

 

29: nobodyさん 2012/09/10(月) 00:08:41.94 ID:???

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

MVCの話をしよう。

 

30: nobodyさん 2012/09/10(月) 00:12:04.21 ID:???
modelの存在感のなさ(笑)
ユーザーの相手はView
ロジックはControllerがするけど…

 

32: nobodyさん 2012/09/10(月) 20:42:11.05 ID:???

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

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

 

33: nobodyさん 2012/09/10(月) 21:32:42.40 ID:???

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

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

 

34: nobodyさん 2012/09/10(月) 21:39:44.83 ID:???

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

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

 

35: nobodyさん 2012/09/11(火) 10:34:58.90 ID:???
原理主義者ってどこにでもいるよね。
自分だけが唯一絶対に正しいと思っている。

 

36: nobodyさん 2012/09/15(土) 10:37:09.58 ID:???
さすがに単体テストの定義が怪しいのはマズイのでは?
そのうち画面1枚を1ユニットとか言い出すぞ。

 

38: nobodyさん 2012/09/23(日) 14:03:17.78 ID:???
俺も気になるね

 

39: nobodyさん 2012/10/05(金) 01:10:53.90 ID:SY4rdWpk
クラスを使いこなせる人間なんて一握りなのに、
その一握りしかうまく作れないMVCって使えないって結論になるよね。
凡人でもうまく作れるような技法を誰か開発してくれんかのう。

 

43: nobodyさん 2012/11/17(土) 16:42:04.07 ID:6UBJdOdB
>>39
別の話だけど、俺も凡人にも
うまく演奏できるピアノがほしいと思う
で、プロになって商売するんだ

 

40: nobodyさん 2012/10/05(金) 20:12:33.86 ID:???
ぶっちゃけ、Mっていらなくね?

 

41: nobodyさん 2012/10/05(金) 20:42:33.35 ID:???
>>40
fat modelが理想なんです

 

42: nobodyさん 2012/11/17(土) 14:01:28.80 ID:xEuSXpZt
おい早くBaiduSpaiderテスター出てこいや!!

 

44: nobodyさん 2012/11/17(土) 20:52:17.68 ID:???
デザパタ語って構造にこだわる原理主義者達、はてなにいそうな人達、なんというか触るとヌルッとしてそう

 

45: nobodyさん 2012/11/17(土) 23:46:34.14 ID:6UBJdOdB

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

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

 

46: nobodyさん 2012/11/18(日) 11:11:00.09 ID:???
>>45
はてなの所はそのままでいいんだw

 

47: nobodyさん 2012/11/18(日) 18:39:27.66 ID:Y/cfCv1C

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

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

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

 

48: nobodyさん 2012/11/18(日) 19:28:07.33 ID:???
>>47
ダジャレの解説とかしてそうだなお前…

 

50: nobodyさん 2012/11/18(日) 20:03:08.05 ID:???
>>47
単語を容易に入れ替えられるような文章から、
相手の言いたいことを読み取れず中身がないように感じてしまうあなたは、
コミュニケーション能力が大きく欠落しています。

 

49: nobodyさん 2012/11/18(日) 19:44:33.14 ID:???
○○にこだわる○○主義者達、○○にいそうな人達、なんというか触ると○○としてそう

 

51: nobodyさん 2012/11/18(日) 21:48:04.43 ID:Y/cfCv1C

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

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

 

53: nobodyさん 2012/11/20(火) 00:56:00.79 ID:???

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

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

 

56: nobodyさん 2013/01/05(土) 03:29:54.86 ID:???

俺のところは

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

のMVSCだな

 

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

 

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

 

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

 

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

 

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

 

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

 

63: nobodyさん 2013/01/06(日) 13:01:06.50 ID:???

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

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

 

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

 

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

ん?

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

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

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

 

66: nobodyさん 2013/01/06(日) 15:33:21.91 ID:???

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

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

 

67: nobodyさん 2013/01/06(日) 15:38:46.57 ID:???

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

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

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

 

71: nobodyさん 2013/01/06(日) 22:32:51.78 ID:???

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

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

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

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

 

68: nobodyさん 2013/01/06(日) 17:03:34.03 ID:???

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

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

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

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

 

69: nobodyさん 2013/01/06(日) 21:26:03.11 ID:???

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

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

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

 

70: nobodyさん 2013/01/06(日) 22:01:20.73 ID:???

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の名前を借りた、意味不明な物。

 

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

 

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

 

74: nobodyさん 2013/01/07(月) 13:42:47.54 ID:???

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

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

 

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

 

78: nobodyさん 2013/01/09(水) 13:35:29.63 ID:???

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

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

 

80: nobodyさん 2013/01/10(木) 00:36:43.40 ID:???

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

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

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

 

81: nobodyさん 2013/01/10(木) 08:43:23.45 ID:???

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

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

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

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

 

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

 

76: nobodyさん 2013/01/08(火) 00:01:08.04 ID:???

フルスタックなフレームワークがあるせいで
1つのフレームワークがあって、それがアプリ全体に
結合しているものみたいな感じになってるからなぁ。

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

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

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

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

図にするとこんな感じ

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

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

 

77: nobodyさん 2013/01/08(火) 00:20:34.96 ID:???

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

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

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

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

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

 

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

>>76-77

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

 

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

 

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

 

86: nobodyさん 2013/01/13(日) 20:09:33.62 ID:???

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

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

 

88: nobodyさん 2013/01/14(月) 08:18:45.08 ID:???

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

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

 

87: nobodyさん 2013/01/13(日) 21:41:23.94 ID:???

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

101: nobodyさん 2016/02/19(金) 02:25:51.39 ID:j7IlO5YC

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

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

 

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

 

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

 

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

 

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

引用元

管理人からひと言

みんなは何使ってるの????

関連記事

  1. 弊社中小企業、Excelのライセンスすら社員分ないw

  2. Wordに詳しいやつちょっと来てくれ

  3. 【IT】厚労省が雇用保険のシステム改修に約50億円計上、統計の不適切調査への対応で

  4. ワオ来年からIT企業勤務、wordとExcelが叩かれる意味がわからない

  5. 【IT】VLCがダウンロード数30億を突破してAirPlayをサポート、いずれネイティブでVRも

  6. 【IT】台東区がCMSのリニューアルを募集 要件:PHPを使用しないこと、サーバ上でDB機能を持たな…

  7. カテゴリ_software

    今一番いいPCブラウザってどれ?

  8. PC買ったらこれだけは買えってソフトを挙げるスレ

  9. 日本のソフトウェ業界はアーキテクトが極端に少ない

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

最近の人気記事

おすすめ記事

新着記事

  1. SES社長だけど質問ある?
  2. windowsにAI搭載するとか言ってるけどさぁ
  3. 新卒エンジニア僕、資格勉強する気が起きない
  4. 文系学部卒一般企業志望の君の進路はここから選んでもらうぞ!→ 営業・販売・未経験…
  5. 正直もうApple<Microsoftになってきたよな

ボンブの戯言

  1. 【ボンブの戯言】フリーランスが払う税金など6選!私たちはこんなに支払っている!
  2. 【ボンブの戯言】ITエンジニアは、なぜうつ病になるのか
  3. 【ボンブの戯言】ITエンジニアがフリーランスになるときに考える・準備すること
  4. 【ボンブの戯言】ITエンジニアが徹夜してでも間に合わせる理由
  5. 【ボンブの戯言】サーバーって何なの(オンプレに限る)
PAGE TOP