やはりDTOを使うのか...
最近ASP.NETで作ったプログラムを焼き直してみる。お題はあるテーブルのデータを検索して一覧表示する処理。
まずはFormの作成から
いきなり手間取るｗ。自動生成されたViewをコピーして、step-by-stepで修正したがなかなか思い通りにならん。CSSの知識が足りない悲しさ。おかげで、いろいろ勉強になりました。
入力データのチェック処理
その前にFormから入力したデータを元のFormで再表示する処理から。...？あのー、この画面、Xという項目に対して複数個条件を指定できるようにしたいから、Formの項目数>Domainの項目数なんですけど？つまりドメインのインスタンスをモデルとしてレンダリングするだけではダメ。こういう場合どうすればいいかGoogle先生に聞いたけど良いサンプルが見つからない。もしかしてと思って自分でDTOを作ったらできたよ。まぁsetter/getterを書かないだけ楽できるけどなんだかなぁ～*1
Formに入力されたデータの取り込み
DTOのプロパティ名とForm上の入力項目のnameを合わせれば一発でFormからDTOに取り込める、と思ったら例外発生。なぜか入力項目以外のものも送られて来ていて、それに対応するプロパティがDTOに無い、ということらしい。仕方ないのでTry＆Errorでその項目をDTOへ追加。しかしこれでいいんだろうか？フレームワークのVersionが変わって送信される項目が変わったら、また例外が起きちゃう！まっとうな手段としてはFormの項目名を指定してDTOにセットすればいいんだけど、それじゃいままでのServletと同じじゃね？
データチェックはvalidation
まぁいいや。とりあえずデータ取り込めたからエラーチェック。DTOに制約条件を書いておけば、validationできるから楽ちん。と思ったら、また例外発生。「ドメインじゃないからvalidationできねーよ(pgr」だってさ～。ちょっとググって公式リファレンスみたら解決。まぁいわれてみればそうだよね。
SELECTの選択肢が消えている
Form送信時送られて来ないから当然といえば当然。今はテストだから固定文字列にしてるけど、本当は別なテーブルを検索した結果を設定することになっている。それを毎回やるの？うーん、無駄だ。でもどうしよう...。最初に取得した時hogehogeに突っ込んで、それを使いまわすか。なんだかServletとかわらないね～。
思ったよりも進まない
まだ擬似SQLを使うところに至っていない。先は長そうだ。
