2011年06月23日

Webサービスでクライアントから大きなサイズのファイルをアップロード可能にする

   このエントリーをはてなブックマークに追加 Clip to Evernote
Webサービスで、巨大なデータを受け取ろうとした場合、
maxRequestLengthhの設定をしても、エラーなってしまいます。(IIS 7 からの制限?)
このような場合は、
Web.configに maxRequestLengthに加え、以下のような記述をしてあげる必要があります。


ここで指定している数は、バイト数です。
デフォルトでは、30000000 のようです。

  

Posted by gushwell at 22:30Comments(0)TrackBack(0)

2011年06月14日

stringの配列からDictionary<string, string>への変換をやってみた

   このエントリーをはてなブックマークに追加 Clip to Evernote
元ネタ:stringの配列からDictionaryへの変換
http://d.hatena.ne.jp/okazuki/20110609/1307577527
http://d.hatena.ne.jp/okazuki/20110609/1307580225
http://d.hatena.ne.jp/okazuki/20110609/1307590523
http://d.hatena.ne.jp/okazuki/20110609/1307590592

僕もやってみました。
奇数番目の要素のシーケンスと偶数番目の要素のシーケンスを作成し、
Zipメソッドで、Tupleに変換したものを ToDictionaryメソッドで、Dictionaryに変換しています。
この例では、Zipメソッドは、拡張メソッドとして使うよりも、静的メソッドとして使った方が、
可読性が高くなると思います。

ジェネリックにしているので、文字列以外のシーケンスに対しても、利用できます。

もっと簡単に書けないかなー。
配列限定ならば、やはりfor文かな。

  
Posted by gushwell at 22:36Comments(0)TrackBack(0)

2011年06月11日

「エマープでかつ上昇数である自然数を求める」を掲載しました

   このエントリーをはてなブックマークに追加 Clip to Evernote
Web Site 「Gushwell's C# Programming Page」に 「エマープでかつ上昇数である自然数を求める」を掲載しました。
Silverlightで書いているので、実際にブラウザで動くプログラムを掲載しています。

エマープ(Emirp)とは、素数を逆転させた数もまた素数である自然数のことです。
例えば、167 は、素数ですが、これを反転した 761 も素数であり、この2つはエマープです。
Prime(素数)という単語を 反転させると Emirp になるので、そう呼ばれているそうです。

また、1479のように、左から右へどんどん大きな数字になってゆく数を、ここでは「上昇数」と呼んでいます。
正式には、上昇数というのかどうか分かりません。もしご存知の方がいれば教えてください。

興味のある方は、ご自身でプログラムを書いてみてください。
  
Posted by gushwell at 11:26Comments(0)TrackBack(0)

2011年06月01日

MVVM:コードビハインドに記述しても良いと思う

   このエントリーをはてなブックマークに追加 Clip to Evernote
Messengerを理解するために自作してみた(1)-(3)
Messenger+Behaviorを理解するために自作してみた(1)-(3)

でとりあえず、コードビハインドにコードを記述せずに、ViewModelからViewを操作する
方法については理解したつもりだけれど、
それでも、今の僕の経験と知識では、コードビハインドに次のようなコードを書いても、
良いんじゃないかなーと思ってます。


こう主張すると、

「コードビハインドにView以外のロジックが入り込んでしまう」
「コードビハインドとViewModelとの蜜結合が起こってしまう」

という意見が出てくるのはわかっています。
しかし、Messengerを使うやり方よりも、こちらの方が、簡単だし、直観的で理解しやすいと思います。

Commandを実装する必要もないから、誰もがわかる普通のメソッドを定義すれば良いだけです。
そして、(XAMLも含めた)コード量も絶対にこちらの方が少ないと思われるます。
開発効率もそれほど変わらないように思います。

ユニットテストでは、ここでいうExecuteメソッドをテストすれば良いと考えます。
ダイアログ表示などは、UIテストでやると割り切っていいのではないでしょうか。
いままでもそうしてきたのだし、その方が自然だと思います。


ViewModelは、以下の3つをやることに専念して、ユーザとの対話は、コードビハインドで
やれば良いと考えます。

・データバインド
・データ検証
・Modelに記述したロジックの仲介

じゃあ、ダイアログを表示する必要が無い場合は、どうするのか?
これも、イベントハンドラで、ViewModelのメソッド呼べばよいと思います。
あとから、その前後でViewの処理をしたくなったら、イベントハンドラにViewのコード
を追加すればいいだけだから、簡単に対応できます。

ViewModelが起点となるView操作はどうか?
これも、ViewMdelのメソッドから戻り値をもらえばいいだけだから、なにも特別な仕組みはいりません。
場合によっては、デリゲート渡してCallbackしてもらっても良いかもしれません


Viewだけで閉じた処理を記述するのも、もちろん、コードビハインドで書けば良いと思います。
わざわざ、ViewModeを経由する必要はないと思います。 必要ならば、添付ビヘイビアを定義すれば良いです。
ただ、業務ロジックに直結するようなものは、添付ビヘイビアは向かない(と思います)。

上記のようにすれば、

・ViewModelの複雑さが軽減されます。
・XAMLも、若干すっきりします。
・XAMLとコードビハインドと、ViewModelとが、ちょうど良い按配でコードが分散してくれます。


ただ、ボタンの有効無効の制御の一貫性を保つのが面倒というのはあるかもしれませんが、
大した問題ではないと思います。
それに、常に有効にしておいて、ボタンを押したときにチェックしても良いんじゃないかと 思います。
無効にしてしまうと、なぜ無効なのかがユーザに理解されないこともありますし...

異論があるのは十分理解しているけど、これが現時点の僕の考えです。
将来この考えが変わる可能性は大いにあります。
それには、

・MVVMフレームワークがVisula Studioに標準として組み込まれる。
・フレームワークが複雑さが隠ぺいしてくれる。
・MVVMデザイナーがVisual Studioに搭載され、XAMLを直接編集しなくてもよくなる。
・これらにより、そのメリットを実感できる。

といったことが実現した時だと思っています。

もちろん、ViewModelを経由した書き方を否定するものではありませんし、
スキルのある開発グループでは、Command + Messenger + Behavior での
開発を採用すればよいと思います。
  
Posted by gushwell at 20:58Comments(7)TrackBack(0)