0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

goldblendをMVCっぽく書けるように、express-goldblend-generator書く

Last updated at Posted at 2015-05-28

準備開始エントリ

相対的理論、というとベロ出し爺さんのアレだが、もう少し日常的な意味で物事は相対的だ。「オタクに理解のあるオタクじゃない人と結婚したい」という考えの落とし穴みたいな記事を読む度に、「オタク」とか「非オタ」とかって相対的なのになーっと思うのだ。ほぼ全ての人は非オタ~「超ヌルい人たちからみればおいらもオタクと呼ばれてそうだが、ガチ勢の皆々様からしたら、おいらなんて非オタだよな」という位置に存在しているわけで、そういう意味では、自分より重度な人が相手では嫌なのか? 嫌だとして、そういう位置を相手に押しつけんのか? という問題な気がするよ。

いずれにせよ、結婚は勢い。まあ色々計算がある人もあろうかと思うけど、「生涯出会う結婚相手候補の数の1/2が顕在化した時点で、それまでに出会った結婚相手候補の平均よりも良い結婚相手候補が現れたら迷わず選ぶ」というのがストリームアルゴリズムとして最適なのは知っておいても良い。まあでも勢いだよ。

冒頭から盛大に逸れた。上記はMVCっぽく、という言い方へのエクスキューズのつもりだったのだが、とりあえず、expressフレームワークの面倒を見るのは誰か、というのからして悩みどころだ。普通にapp.jsに入れるのか。MVCの前に初期化フェーズはあって、相互のメッセージングとかに関して面倒を見ておくべきことはinitの役割で、そういう意味で「app.js」で問題はない。でも、例えばセッション機構の面倒を見るのは、どう考えてもmodelだし、route設定はcontrollerだけど、リダイレクト経由先のrouteは、表示系を管理するviewにくっついていた方が良いから(とゆーか、それをSyntax Sugarで一行で書こうぜ、というのがgoldblendだから)エンジンを初期化する過程がちぎれるなあ、とか思うのだ。

まあ、自分のMVCの理解なんて、views:テレビに出るもん、controllers:ジョイカードから来るもん、models:それ以外、なので、まず、自分のイメージ通り素朴にディレクトリ構造考えてみた。

//自明なディレクトリは省略して、中身だけ書いてみた
project root/app.js //エントリポイント
  public/**/*.{html,jpg,css,js} //各所のpublicをツールでかき集め
  module_a/header.js //モジュールの公開管理
    module_a/views/view.js //見せるもんの親玉で、表示パラメータもmodelsから引っ張ってくる
      module_a/views/template/*.ect                //加工して見せるもん
      module_a/views/public/**/*.{html,jpg,css,js} //そのまま見せるもん
    module_a/controllers/controller.js //来るもんを捌く親玉
    module_a/controllers/getpost.js         //フォームボタンとかから来るもん
    module_a/controllers/socket.js          //外部アプリから来るもん
    module_a/controllers/api.js             //WebSocketから来るもん
      module_a/controllers/public/client.js //クライアント完結のコントローラ(jQueryコード)
    module_a/models/model.js //中身の親玉
      module_a/models/logic/logic.js        //状態管理とか
      module_a/models/logic/data.js         //使うデータ構造のハンドリング
      module_a/models/logic/public/logic.js //オフライン用:状態管理
      module_a/models/logic/public/data.js  //オフライン用:使うデータ構造
    module_a/modulecommons/common.js //共通ライブラリ
      module_a/modulecommons/wrapper/api.js       //外部アプリを使うときの舵
      module_a/modulecommons/wrapper/extmodule.js //外部モジュールを使うときの舵
  globalmodels/globalmodel.js //大局的な状態管理
    globalmodels/models/logic/logic.js        //状態管理とか
    globalmodels/models/logic/data.js         //使うデータ構造のハンドリング
    globalmodels/models/logic/public/logic.js //オフライン用:状態管理
    globalmodels/models/logic/public/data.js  //オフライン用:使うデータ構造
  commons/common.js //共通ライブラリの親玉
    commons/wrapper/db.js         //データベースの舵
    commons/wrapper/api.js        //共用の外部アプリを使うときの舵
    commons/wrapper/extmodule.js  //共用の外部モジュールを使うときの舵
    commons/wrapper/system.js     //ログとか上位のnginxとかへのメッセージングの舵
    commons/utils/message.js      //デコード・エンコード・共通のお約束
    commons/utils/abstract.js     //Yコンビネータその他のハック

駄目だ。めんどくせえ。expressちょう楽ちん、なはずだったんじゃ……。

viewsの下にとりあえずコードがあって、publicがviewsの下にあったりするのは、世の中的にあまり見かけないが、自分的にはすっきりする。いや、viewsってこうだろ。

controllersもそうだよな。フォームから来る、Websocketから来る、外部アプリから来る。

問題はmodelsだ。これ、model.jsは全体のラッパーみたいになるから、可視管理すんの?logic.jsとdata.jsとutils/をmodule.exportsし直すのがお仕事?それでいいん?

最初に楽ちんに書くにはどうしたら良い? logic.jsとdata.jsを往復してこちょこちょ。ざっくりとしたロジックを作る。view.jsで数画面作ってこちょこちょ、getpost.jsでいくつかユーザの入力を受け付けてみて、なんてやるんか? おい、だいぶめんどくさくなってねーか? あちこち飛び回りすぎねーか?

最初はlogicスコープ、dataスコープ、controllerスコープ、viewスコープをapp.jsの中に直書きして、どっかでツールで分解するか? 自己requireしてスコープ内からでも他ファイルを参照しているつもりで書く、なんてやり方、javascriptだと出来るんか?(古い話、Cだとヘッダファイルだけ分けといて、コンパイラスイッチで複数回同じソースをコンパイルしてリンクする、なんて技があった)どこでその分割する決断するんだ? jQueryコード、publicと遠い場所で書いて大丈夫か? それは見通し悪いままか? シンボリックリンクでごまかすか? デプロイ困んないか? app.js起動時に生成する形で、jQueryコードをviewsから作るんか? それ、稼働中に再作成できるようにすんの、めんどくさくないか?

さあ、繰り言タイムだ!

RADツールなんて言葉使うと、またおっさんぽくなるけど、RADツールって、元々Controllerの中に全部書けます。楽ちーん。っていう発想だよね。viewはGUIでぺたぺた。いじるときはControllerからやってね、な感じ。基本的に。VB-MFCなんて、触りたては、「えっと、なにかクリックとかされないと手足もがれた状態ってことですか?」的なあわあわ感がある。

MVCなにそれおいしーの的な世界。最初書きやすいツールはほとんど、Controllerに全部入ってくる。なんか、WEBもそうなんだよな。元よりこのステートレスな仕組みが、それに向いた仕組みになってる。ちょう有名な「やはりお前らのMVCは間違っている」とかに言うとすれば、「とゆーか、RADツールの末裔にMVCを求めるお前も間違っている」っていうところかもね。

で、どうするよ。とはいえ、書き始めたは良いが、行き詰まるなんてのはやだ。基本的に、コーディング速度がなるべく尻上がりに上がるような設計が良い設計で、知恵がなければ、コーディング速度はプロジェクトサイズと負の相関で次第に鈍化するという、世の中の摂理に抗えない。そういう意味でMVCは正しいのだ。RADツールだって、さきっちょだけ、と言われて、きもちー!、とか思わせて、やがて時が流れて、なんかもうこれ以上の規模はムリ、という末路を辿るもんだ。でもね、欲張りさんなのは分かるけど、最初から楽に書きてーんだコノヤロウ!

たとえばさ、気の利いたアンケートエンジン作ってみようとかするじゃん。すぐできるじゃん。それを包んだプレゼンテーションツール作ってみようとかするじゃん。プレゼンテーションツールはSPAになるっぽいじゃん。アンケートエンジンの結果を使いたいじゃん。みたいに夢が広がっていくんでしょ。そういう風に開発したいよね。そうすると、新しいMVC完備したモジュールを作って、単体で研いて、繋げてってのもやりたいよね。

express-goldblend-generator -m module_b

みたいに、この箱の中に新しい箱を作るっていうのもgeneratorでやりたいんよ。ものによっちゃ、これほとんどそのまま組み込みてー!みたいなことも考えるよね。ラッパー書いて自分の構造に埋め込むよね。それを全部カバーしようと思うとこんな感じなのだよ。

どう始めるか。どう踏み込むか。かんがえちゅう、というお話でした。

アイディアあるならおくれ。URLでもいいよん。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?