L'eclat des jours(2013-10-25)

_ WebMVCと設計パターン WebMVC（面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい）というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装（貧血）と最悪のDomain Model実装（鬱血 ）が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど

[yyamano]

プログラマは構造が好きだから、解決しようとしている問題が何かを忘れちゃうんだよね。

[tarchan]

＞特定パターンの知識を頭にたたき込むことではなく、そのプログラムの仕様を実現するには、どうすれば最も効率的（実行効率、保守効率、作業効率、管理効率、検証効率、配備効率などなどのさまざまな切り口について

[ledsun]

Fat Controller問題なんてアプリの規模と用途次第でしょ、論。

[paz3]

『本当に必要なのは、MVCそれぞれの責務がどうしたというような特定パターンの知識を頭にたたき込むことではなく、どうすれば最も効率的なのかをさまざまなケースについて独立して考え、実装できることだ』

[lizy]

「コントローラに直接スクリプトを記述するスタイルだ」そんなパターンじゃなかったような……Cから呼ばれる処理の塊なのでは

[yass]

"なぜOKなのか？ とは考えない。なぜだめなのかを考える。保守性が低い？ 別に低くない。見通しが悪い？ 全然悪くない。だめな理由は「それはMの責務であって、Cの責務ではない」という教条主義に抵触するというだけだ"

[PaulYamamoto]

その通り、本当にその通り。ただでさえWebもRDBもOOPとは相性が悪いんだから。

[innx_hidenori]

公理となっているアーキテクチャが要件に適していればそのまま採用することで、設計的判断を必要時まで保留しつつ、必要な問題に取り組めると考えます。

[shin1x1]

適材適所 / リーダブルなコードが良いのは当たり前なので、デザインの話とは違う気が

[toenobu]

mvc

[yujiorama]

"なんでも同じやり方を適用しようとすることこそ避けるべきことなのだ" 列挙されてる効率は品質特性のものかな

[t-wada]

“どうすれば最も効率的なのかをさまざまなケースについて独立して考え、実装できること” "リーダブルなトランザクションスクリプトパターンのほうが、アンリーダブルなドメインモデルより数1000倍良い"

[marmotY]

全くもって同意。状況に合わせて最適な選択ができるのが最良。

[moro]

"リーダブルなトランザクションスクリプトパターンのほうが、アンリーダブルなドメインモデルより数1000倍良い。" それはまったくその通り(野生のコードでは、前者になかなか巡り会えないけど)

[yojik]

PofEAAでは、トランザクションスクリプトもドメインモデルも「ビジネスロジックパターン」であり、こういう風に(Web)MVCの議論とは完全に切り離して考えることが可能。(MVCはWebプレゼンテーションパターン)