繰り返される MVC model 2 の話
以下、ここまでの流れを追わずに、主に放言だけ。いろんな方があれこれ書いていて。TL で目にしたのだけでも収集つかないし、断片的すぎるし、書いてる時にほとんど読んでいなかったので。他の人のは、ここから後で交錯した部分だけ引用させていただくよ。
話題の流れの情報収集
といいつつ、流れにはのっていない。(^^;
- 21:59:21
nsiena: 流れが分かってないけど、MVC2 が話題なの? - | 22:04:22
uokumura: @nsiena ごめんなさいそこに飛んでるのたぶん私だけです。震源は http://bit.ly/ygzrQ ここです。 - || 22:07:22 nsiena: @uokumura thx! 読んでまわるるる。
- 22:44:22 nsiena: #article 読んでる: 「Seaside へ GO!! -- 楽々サーバサイド Web プログラミング -- 第２回:コンポーネントの作成」<http://bit.ly/49awWH> : Seaside の MVC の説明
- 22:51:22 nsiena: #article 読んでる: 「GUI Architectures」<http://martinfowler.com/eaaDev/uiArchs.html> : Martin Fowler の。もう 3 年以上前になるのね。
この他にもいろいろ目を通したけど、メモするほどでもないので措いとく。
- 22:58:22 nsiena: 読んで回るのに飽きた。MVC2 の出た頃から、繰り返されてるような話が多いような気がする。
- | 23:01:23 uokumura: @nsiena ごめんなさいなんどもおんなじ事繰り返してます^^;
- || 23:11:23 nsiena: @uokumura あーいや。MVC != MVC2 なのは同意なので ^^; あちこちのブログの一連の騒動というか、このクラスの人達が何をやってるのだろうかと。ちょっとがっくりしたの。
- 22:58:22
yugui: Railsから入った人やPHPから入った人はJavaEEアーキテクチャパターンの歴史から学んでない傾向があるとは常々思ってたけど、SIどっぷりな人も逆に軽量なアーキテクチャがあり得ることに思い至らないのかな? でもSunの資料には軽量アーキテクチャも載ってたと思うんだけど
MVC2 ってこういうものでないのかな
- 23:02:23 nsiena: とりあえず。MVC2 において、Model != DB。同一視するな。Coltroller には、経路制御用のコード以外書くな。View に制御用・データアクセス用・データ処理用のコードを書くな。
ついでに書いておくと。View != テンプレート。View は、テンプレートエンジンとカスタムコードとテンプレートの組。"Model == DB ∧ View == テンプレート" みたいな紹介をするのは止めて欲しい。真意を理解できない人が、コードを Controller に流入させてしまう原因になりかねないので。
また、Controller は Model-View の組ごとに用意するのが MVC 的。MVC2 では、複数の Model群, View群をまとめて面倒見ちゃうスタイルもよく目にするけれども。
- 23:04:23 nsiena: Model が分厚いの上等。というか、Model 内は、サブモジュール分割するなり、レイヤ化するなりして、粒度を下げるもの。MVC は、外界と内部モデルとの境界しか担当しないのだから当然。
- | 23:09:23
asatohan: @nsiena 僕も普通にそう思ってたんですけど、世間的にはそうでもない考えがある感じなのかな＞Model 内は、サブモジュール分割するなり、レイヤ化するなりして、粒度を下げるもの - || 23:15:23 nsiena: @asatohan 世間的にというか、こんな悪夢を妄想(謎): ウェブアプリは簡単に書けるんだよねー? → フレームワーク使えば理解してなくても書けるんだ、へー → MVC ってのがあって、M が「データ」なんだ、ふーん → データ処理以外はどこに書くんだろ、どこでもいいや
わーい。Yugui さんに RT られたー(←
Model の上に Service と呼ぶモジュールを用意するというような主張も時々見受けられるけれど。それが本来の Model の本体ではないのかな。Model を誤解しているように見えて仕方がないのよね。
MVC2 でいうところの Model は、データではなく、アプリケーションの論理的なモデル (を実装したモジュール)。で、ActiveRecord パターンで作られるモジュールは DB の抽象化であって、Model のプリミティブな構成要素にすぎない。それなのに、Model == DB とみなしちゃうから、Model の構成で困って Service なんてものを引っ張り出す羽目になっているだけではないかしらん。*1
MVC2 以外のアーキテクチャもね
他のフレームワークを使うとか、別のアーキテクチャで構成するとかも。ちゃんと選択肢に入れておいた方がいいよね。
- 23:21:23 yugui: @nsiena PACを我流で習得しようとして挫折して再挑戦の機会を狙っている私です。
- | 23:25:23 nsiena: @yugui PAC の方がいいですね。複数のリソースをまとめた複合リソースみたいのも作りやすいんじゃないかと思ったりしてるです。あるいは、プロトコルスタックとの親和性から多層モデルとかはどうかしら。とか。どれも基礎的アーキテクチャだけど。
Yugui さんが挫折とかほんとかなー。もしや、挫折するような壮大な計画が(ry
- 23:27:23 uokumura: PACも勉強してみたいなぁ。Ecripse？
- 23:28:23 uokumura: PACで、MVCの例によくあるような1オブジェクトに複数ビューってどうやるんやろ？
見落としてた。というか、TL をあまり見てなかった ^^;
複数の Presentation を対応させる、じゃないのかな。違うことを考えてるのかも。
アーキテクチャの持つ制約と制限も意識しよう
- 23:29:23 asatohan: すごい適当な考えだけど、ある意味MVCアーキテクチャパターンを具現化（？）したフレームワークを使う時点で、フレームワークの使い方だけでなくMVCのアーキテクチャ的な制約も課せられていることになるんだよな。制約違反が存在することと、できれば、制約違反を検出したいという感じか？
- 23:31:23 nsiena: @asatohan ですね。欠点がないものなんて、そうは存在しないので。でも、制限をねじ伏せて、歪もうが、腐ろうが、それ一つでやりきろうとしてしまう人達がいる。ふしぎ。
- 23:34:23 nsiena: @asatohan アーキテクチャレベルの abuse を発見するためには、よりメタな監視者が必要かしらん。それを体系的に発見するために必要なのは、メタアーキテクチャなのか、メタモデルなのか。人が経験的にチェックするのでは、abuse はたぶん止まらない。悲しいことに。 [※ 言いたいことをちゃんと書けてなかったので捕捉 (2009/10/15 Thu 22:15)]
- | 23:38:23 asatohan: @nsiena できれば、人がチェックするのは避けたいところですなー。人が行うのは、制約とかルールなんかの記述だけにしたい。
- || 23:45:23 nsiena: @asatohan 「人がチェックする」はちょっと表現が不適切だったかも。「人が理解して、制約と制限を適切に沿うように意識する」くらいの意味合いで。ツールで解決ってのはありだけど。それを意識しようとしない人は、小うるさいツールくらいに思って、そもそも使ってくれなそうな罠。
- ||| 23:48:23 asatohan: @nsiena 了解。僕は完全にツールのこと考えてました。＞人がチェック
- 23:31:23
- 23:31:23 asatohan: ってことで、OOPLSA2005の"Using Dependency Models to Manage Complex SoftwareArchitecture"の論文思い出した。(PDF) http://bit.ly/2iXQdG
- 23:33:23 asatohan: けど、あんましMVCとは関係ないかも。
*1:ここの話とは関係ないけれど。「サービス」ってのも便利に何にでも使われすぎてて、紛らわしくて意志疎通の障害になりやすいなぁと、たびたび思う。「サービス」という言葉を使わない、もしくは、「ほにゃららサービス」というように限定するようにした方がいいのでないかしらん。
