MongoDBインストール（Mac OS X Homebrew）

homebrewでmongoDbインストールしてみた。
参考：http://www.milligramme.cc/wp/archives/2994



brew install mongodb
==> Downloading http://fastdl.mongodb.org/osx/mongodb-osx-x86_64-2.2.0.tgz
######################################################################## 100.0%
==> Caveats
To have launchd start mongodb at login:
    ln -s /usr/local/opt/mongodb/*.plist ~/Library/LaunchAgents/
Then to load mongodb now:
    launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mongodb.plist
Or, if you don't want/need launchctl, you can just run:
    mongod
==> Summary
/usr/local/Cellar/mongodb/2.2.0-x86_64: 20 files, 170M, built in 15 seconds

と一発でインストール完了。
続いて、

mongod &
mongo

> j = { name: "mongo" };
{ "name" : "mongo" }
> db.thingy.save(j);
> db.thingy.find();
{ "_id" : ObjectId("508b83edb38f2b4b29878958"), "name" : "mongo" }
> 


動いている。

次はPHPからMongoDBを動かしてみる。
参考：http://blog.ville.jp/2012/07/18/1058

sudo pecl install mongo
php.iniに次の項目を追加。

[mongodb]
extension=mongo.so

phpinfo()で確認。

ここまで簡単でした。
しかし、上の記事ではMongoDBが散々に書かれてますねｗ

DCIを調べてみて、MVCについて思ったこと

Data, Context, and Interaction (DCI)というのが流行っているらしい、と聞いて調べてみた。なにか「とてつもなく面白そう」なので、何か書いて見る。

全然理解はできていないので、あくまで連想したことです。

MVCは１リクエストに対して１リスポンス

自分の理解では、ウェブ・アプリケーションでのMVCとはリクエストに対してリスポンスを返すためのデザインパターンであること。

MVCについては、MOVEやらCが太るとか言われてますが、基本的にはhttpの仕組み上、この考え方は理にかなっていると思う。

ただ、人間が操作する場合を考えると、MVCだと何かが足りない気がする。

非常に単純なケースとして、新規データの登録を考えてみる。
　１）フォームを表示(form)、
　２）入力されたデータの確認画面(confirm)、
　３）データベースに登録(insert)、
という流れで処理が行われていると思う。
実際には、もうちょっと複雑なことが多い気がする。

さて、MVCだと、上の処理を３回に分けて記述する。
一つ一つの処理は理解しやすいのだけど、流れとして見た場合に処理のつながりが追いかけにくい。と思う。

Interactionをコードにする

DCIだと、どうなるのだろう？
こういった処理（インターアクション）をコードとして記述しましょう。
という事らしい。

早速擬似コーディング。
こんなかんじかな。

function add_entity( $action, $ctrl, $view )
{
    $role = $ctrl->getRole( 'entity' );

    if( $action == 'form' ) {
        return $view->showForm( $role );
    }
    $ok = $ctrl->verifyInput( $role );
    if( !$ok ) {
        return $view->showForm( $role );
    }
    if( $action == 'confirm' ) {
        $view->setToken( $ctrl->getToken() );
        return $view->showConfirm( $role );
    }
    if( $action == 'insert' && $ctrl->tokenOk() ) {
        $role->insert();
        $role->vanish();
    }
    return $view->showDone( $role );
}

$ctrlや$viewが何かというのは考えないで。

実際に操作する対象は「entity」。
それをRoleで包んでいる。この例だと、単にActiveRecord化してる。

さて、$actionは「form」「confirm」「insert」と進んでゆく。
$view->showForm()からは「confirm」をアクションとして、
$view->showConfirm()からは「insert」をアクションとして、

呼び出す。

そして、すべてのアクションで同じ処理（add_entity）が走る。

どうだろう？
これだと何が起きているのか、分かりやすいと思う。
まぁ、ちゃんと動くのが前提ですが。

Interfaceを使ったDIの問題点

PHPのインターフェースを使って、簡単に依存注入するコードを考えました。
が、これぐらい誰かがすでにやっているはず。

と思って探してたら、見つけた。
「Symfony2: Dependency Injection Types – Update」

これによると、過去にSymfonyでインターフェースを使ったインジェクションがサポートされていたらしい。で、ここのスレッドでの話し合いの結果、問題があるので機能そのものを削除することになった。

何度も読んだが、今ひとつ理解し切れないのだけど、
おそらく、

1. インターフェースインジェクションを持つクラスAを継承して別のクラスBを作成、
2. 別クラスBに対して「自分でインジェクション」を行う、
3. が、SymfonyのDIコンテナがクラスAとBを混乱、
4. クラスBに対して再びインジェクション実行、
5. 最初に自分でインジェクトした結果が上書き、

という流れのよう。

ようするに、
インターフェースは継承したクラスにも含まれるので、
依存注入のコントロールが難しい、
ということだと思う。

正直に言えば、同じインターフェースで別の依存性を注入するのが問題な気がするが、できるのだから、できるようにしないといけない。

とにかく、見つけてられて、すっきりした。
インターフェースを使った依存性の注入はやめておこう。