Ria ServicesのEntitySetは自動でリフレッシュしない

相変わらずまたビジネスSilverlightをやっていたりする…
そして、Client側にデータを蓄えてステートフルなUIを組み立てできるのはやっぱり便利！
とか改めて見直したい気持ちになっていたりする。

とわいえ、グローバルVMは依然メモリリークが怖い。
あと、どうも一旦LoadしたEntityは追加でQuery&Loadしても最新状態に自動ではレフレッシュしてくれないらしい！
想定してない動作だったのでちょっとびっくりした。

で、それをするには、load時にLoadBehavior.RefreshCurrentを指定する必要があるらしい
http://weblogs.asp.net/fredriknormen/archive/2009/11/24/refresh-the-cached-entityset-after-a-submitchanges-wcf-ria-services.aspx

記事にもあるように、サーバー側の削除をLocalなEntitySetに反映させるにはさらにおまじないが必要だったり
loadするqueryにサービス側でIncludeを指定して依存Entityの同時loadを行っていたりするとさらに予期せぬことが起こったり
とにかく、LoadBehavior.RefreshCurrent指定だけで簡単に済む話しではないようだ。

ということで、結局はLoad前にEntities.Clear()するのが吉。
となると、ステートフルな状況とどのタイミングでClearするのがいいのか？でまた混乱したりする。まで進んで、
ちょっと前のこともなにも覚えてないWebアプリのアルツ具合がステキに思えてくる。
と、いったりきたり…

結論はいつもとおり、そこは要件に合わせて使いわける！ で落ち着く；；
で、それもしやすい。ということで、クライアント側はJavaScript＞Silverlight。てことになるのかな？
今年はまったく手が付けられなかったOnePage。とかにも、いずれ着手が必要なんだろう。

「新しい」は目的ではない！ は、もちろんそうだが、
改良の結果として現れてくるものが「新しい」のもまた真。
変える必要のない価値があるのもそのとおりで、
価値はそのままにして手段を変える必要があるのも、またそのとおり。 なんちゃって
になんとか老人パワーを滑り込ませる

12月の月

今年はホワイトクリスマスだ。
寝る前に外に積雪を確認しにいったら思いがけず空は晴れていて月がでていた。
12月の月は高い。

子供のとき、母について、月の夜に田んぼの大根を掘りにいったことがあった。
雪の下に大根が生きているのも不思議だったが、
満月に照らされた雪の世界は夜とは思えない明るく、きらきらと光っていて、
静かで、凍っていて、その美しさは言葉にはできない不思議に満ちていた。

そんな不思議はいろんなところにあり、それを神と畏れて生きていた僕の祖先の神は
ニーチェが死んだと言ったその神とは違っている。よね？
は、どうでもいいけど、とにかく
冬、月の夜には、自分がいなくなった世界の永遠をしばし感じることができる。

「商才がない」を改めて実感している

自分の欲しいものと、世の中に売れるものが違うことがある。
自分中心なので、世の中のセンスがズレていると思うのだが、
自分のセンスがズレている。が正しい；

それは仕方ないとして、そうゆう人は商売も難しくなるような気がするが、どうなんだろ？
もしかすると商人は、自分は欲しくはないけど売れるものはわかる！のかもしれない。
そうなれば、その人の商品はもはや売っている商品そのものではなくその才能だ。
それだって立派な商品だ。というかすごい価値だ。
が、その人はその人の商品を正しく伝えてはくれない。ので、よく聞かないと混乱する。
選挙のニュースで、ふとそんなことを思った。

そうゆうのは面倒なので、
「私の商品は本当はこっちなんですよ！」とはっきり言ってくれればいいのに！ と思う。
オラが欲しいものは、そうゆう面倒くさくない世界だ。
が、それは言わない（気付かない）！が、絶対的戦略なので、その夢はかなわない。
欲しいものと売れるものはやっぱり違う。

そのズレはなかなかに大きい。
隔たりが大きすぎて、自分が願いはそれがほんとうにありえない子供じみた妄想に思えてくる。
しかしまあ、現状商品に対する他の人の評判もやっぱりひどいものなので、
いずれはニーズにあった十分に良い商品が提供されるようになるのだろう。

ひどい嫌悪を覚えるのに、つい興味を持ってしまうのは、
そこに改善余地がたくさん残された、需要が満たされていない優良な市場が見えてしまうからだろう。
が、自分には売るものがない(T.T)

科学的な経営

白黒はっきりつけたいときは「科学的」は役にたつ。
なので、「いってーどっちなんだい！？はっきりしろーー！！」的な設問には科学的に答えるのが良い。
そうゆう答えを求められる僕らは、「科学的」を学習するしか仕方ない。

たとえば、経営がどうも調子が悪ければ、経営の科学が必要になる。
http://business.nikkeibp.co.jp/article/opinion/20121205/240603/?mlp

おうよっ そんな（オカルトにつきあってる）ヒマはないぜっ、科学的に効率化！
って… しかし考えてみると
経営学者が勝負をしているのは「経営学」レースであって、「経営」レースではない。 ので、
たしかに、すでにある技をいくら学習しても新しい技を教えるビジネスのネタにはならない。

さて、問題は「科学的」な経営学がどれだけ経営に貢献するか？ とか、あるいは、
科学的な経営とは破綻しない経営なのか？それとも破綻が約束された経営なのか？とか、
アップル社のV字回復を成し遂げた英雄伝説も身近にあったりして、
最初から疑念が入り込んだりする→科学的；；；

それでも、少なくとも「非科学的」な経営よりは１００倍マシ！
と思っている、オレオレ経営にウンザリしている会社員はゴマンといそう。
（経営科学の意義はそのあたりか…）

とにかく、「科学的」は推奨されるし、その探究は進み、
いずれは、英雄伝説も科学的に十分に解説されるようになる。かもしれない。
そして今現在はその未来ではない。ので、科学的はまだ万能ではない。
いつか万能になる日が来るのか？も証明できていない。
逆に、科学は万能じゃない！も証明できていない…の？？？

科学は万能！は、科学的に証明が必要。が、
科学は万能じゃない！は、科学的な証明は不要。
白黒つければ科学的が負けることはない。が、
白黒つけなければ科学的が勝つ意味はない。

経営が失敗するのは、
科学的が足りないからとも言えるし、科学的を頼りすぎたらからとも言える。
スタンスをどちらかに決める必要はなく、頼り過ぎずにより先を目指せばいいだけ。
客観的には、せいぜいたかだかに価値をつけすぎ！という警鐘は多い。
もしどうしても科学が必要な状況ならば、もっと高いレベルを要求したほうが良い。
なんちゃって；

RavenDBではリポジトリは必要ないらしい

http://novuscraft.com/blog/ravendb-and-the-repository-pattern

なぜなら
・ インピーダンスミスマッチがないから
・ 十分良いAPIがあるから
・ そのままLINQでアクセスできるから

例えば、EFMVCはコントローラとストレージの間にリポジトリもあるし、コマンドプロセッサもある。
が、それはストレイジがSQL Serverであり、EntityFrameworkを使うから必要なのであり、
代わりにRavenDBを使うならそれらは必要なくなる。ということか。

もちろん、他に何か別の理由があるならリポジトリを追加することはできる。
が、明確な理由がなければ使う必要はない。らしい。なるほど！
もっとつっこむと、何か明確な理由がなければSQLServerを使う必要はなくて、
やりたいことに十分であれば、RavenDBを使った方がコードはよりシンプルになる。てことなのだろう。
生い立ちを考えれば、当たり前といえば当たり前だけど；

リポジトリの役割を論理的に理解しようとする（している）と、
その理屈からすれば、RavenDBだからと言って、リポジトリがいらなくなる理由を簡単に納得できるなくなる。
ことはありそう。そうだとすれば、その理解も疑ってみてもいいのかも。

いつのまにか手段が目的化してることはありがちなので…
前提を覆して考えてみることはいつでも有効なのだ。
とにかく、RavenDBを使う場合、リポジトリも、もしかするとDIも
それが本当に必要になるまでその適用を保留していいのだ。