RIAフレームワークと「用美道」

RIA開発にはいろんなフレームワークがありますが、なんか俺には敷居が高いのです。Smarty(とちょっとだけcakePHP)くらいしかマスターできん。 「用美道」てのはこのまとめでちょっとだけ触れてますが、ここでは「valid」「simple」「adjustable」の意味で使っています。フレームワークにも用美道が必要と、思い余ったあげく、つぶやきまくったのをまとめました。
0
smw @Shi_MeiWo

記述量の増えないフレームワークがあれば売れる、きっと。フレームワークの使い方を覚えるために工数をかけるなんて本末転倒に思えて仕方が無い。

2011-06-02 02:48:10
smw @Shi_MeiWo

理想的なフレームワーク ・記述量が増えない ・習得しやすい ・書き手によって差が出ない ・ソースが読みやすい そしてなにより ・バグを産まない/デバッグしやすい

2011-06-03 11:08:01
smw @Shi_MeiWo

cakePHPにしろ、PureMVCにしろ、技術者的潔癖さの代償か、覚えるべきことが多すぎる(cakePHPは独特の「マジック」が、さらに俺を迷わせる)。思うに処理を「多段階」に分けて、「参照渡し」をぶんぶん振り回すことで、高度に「抽象化」させようという腹積もりなのだろう

2011-06-03 11:12:18
smw @Shi_MeiWo

でも、MVCの考え方は、少しでもシステム全体をスッキリかんたんに整理する為の物だったはずだ。整理されてれば改変も、改変の影響範囲もひと目でわかる。少なくとも、ごてごてと技術のデコレーションを盛るために考案したわけではないはずだ。

2011-06-03 11:15:34
smw @Shi_MeiWo

参照渡しだって、俺は「記述をスマートに(直感的なコードがかけるという意味)出来る」から使うのであって、たくさんの参照をあちこちに振り回せば、これはもはや一種のGOTOのようなもの。コードではなく、レジスタ参照のスパゲティだ。

2011-06-03 11:18:27
smw @Shi_MeiWo

日本武道は「用美道」、すなわち各技術が「有用であること」「単純であること」「制御可能であること」を尊ぶ。でもこれって、武道に限らず、あらゆる芸事で言えることではないかな。カッコよく飾ったからといって、優れたものだとは限らない。

2011-06-02 02:55:35
smw @Shi_MeiWo

今は時間がないのでこれ以上話せないが、いつか、「じゃあどんなフレームワークがいいのよ?」を考えてみたい。

2011-06-03 11:20:13
smw @Shi_MeiWo

MVCを、もう少し分かりやすくすると、「倉庫」と「画面」と、橋渡し役の「窓口」であり、窓口が受け取った要求を、倉庫から引っ張って来て、画面に表示・・・という流れになる・・・とすれば、分かりやすいかな?

2011-06-03 22:52:14
smw @Shi_MeiWo

じつは窓口と画面については、非常に良い既存技術がある。そう、PHPの「Smarty」だ。これは「プレゼンテーション」と「ビジネスロジック」の分離だが、分離の際に、明確な意志が見える。「画面を構成するための配列やループは、プレゼンテーションでも喜んで使う」ということだ。

2011-06-03 22:55:45
smw @Shi_MeiWo

「画面デザイナにロジックを考えさせるな!」という常識に「意味のある繰り返しの表示は、”画面デザイン”だ!」と牙を向く。このSmartyの頑固さを、倉庫、画面、窓口の三者で保つようにすれば、最低限の約束事で、ある程度の形あるアプリケーションを作れるかもしれない。

2011-06-03 23:00:33
smw @Shi_MeiWo

近代プログラミングにおける基礎単位、それは「タプル」。見出しと内容(あたいだろうが処理だろうが、何でも入る・・・タプル自身さえ入れられる!)が1対1になったものが、たくさん束ねられたもの。根源的な構造体であり、アレー、リスト、オブジェクト等の始原。アルファでありオメガ。

2011-06-03 23:07:00
smw @Shi_MeiWo

このタプルを、倉庫、画面、窓口の間で受け渡すようにする。ちょうどSmartyで、配列や連想配列をテンプレートファイルに丸投げして、じゅうぶん用事が足せるように。物事はよりシンプルな方が正解である。用美道の「美」(シンプルさ)というやつだ。

2011-06-03 23:10:56
smw @Shi_MeiWo

基本的なルールは、窓口の中に、倉庫と画面のインスタンスをつくり、それに対し操作してゆくのがいいだろう。タプルという構造は、各言語ではあまりにもアトミック過ぎて採用していないはずなので、適宜、配列や連想配列として考えればいいだろう。

2011-06-03 23:14:09
smw @Shi_MeiWo

そして、これは分の悪い賭けというか挑戦だが、jQueryの「マジック」を使いたい。つまり、オブジェクトのメソッドの戻り値は、オブジェクト自身への参照。これはとくに「倉庫」の読み書きに、強力に働いてくれるはずだ。

2011-06-03 23:18:13
smw @Shi_MeiWo

さて、倉庫からの読み出し。倉庫はDBと仮定しよう。通常はSQLを書くところだが、窓口からはO/Rマッパーで呼び出したい。$model->price->greater(2000)で、その行全体が連想配列になっている、該当行分の配列が、ずるっと引き出されてくる。うわー効率悪いwww

2011-06-03 23:36:22
smw @Shi_MeiWo

倉庫はmodelで表したけど、基本的にはDBのテーブル。ただしテーブル結合は、結合情報を倉庫として定義するほうが、窓口の負担がなくてよいだろう。いわゆる関心の分離。

2011-06-03 23:39:48
smw @Shi_MeiWo

さて、jQuery的なアプローチだが・・・$model->price->greater(2000)->tokubai_flg->set(true)->price->set($it * 0.08)で、値段2000円より上の商品の特売フラグを立て、価格を2%下げる・・・ムリ、かな?

2011-06-03 23:50:58
smw @Shi_MeiWo

まぁ仕様は全然考えてないけど、こんなアプローチなら、恰好でも楽に大きなRIAを組めるんじゃないかなー、と。なんか思いついたらそんときに追記する。

2011-06-03 23:53:45