- - PR -
ASP.NET プログラム作法について 書式整形はいつ行うべきか
1
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-02-01 22:56
初めましてhigeといいます。
無印ASPからの移行で、OO指向関連で戸惑っている初心者です。 表題の件について皆様のご意見を伺いたくスレッドを立てさせていただきました。 例として、以下のような案件があるとします。 1. 商品の入荷日と商品名、分類コード( 1, 2の数値を選択)を入力するフォームがある 2. 登録ボタンと照会ボタンを備える 3. 登録ボタンを押すと1のフォームのデータがDBに登録される ただし入荷日はフォーム上年、月、日ごとのテキストボックスに別れており、 DB上の入荷日フィールドはDateTime型である 4. 照会ボタンを押すと、DBの内容が全件一覧表示される この際、分類コードは1ならば「野菜」、2ならば「果物」の対応で表示させる 5. 登録処理はApp_Code以下、hogeクラスのinsertRecordメソッドを使用する 照会処理も同クラスgetRecordメソッドを使用する この案件において、登録処理時、入荷日は年月日のテキストフィールドからDateTime型への変換、 また照会処理時には分類コードの数値 -> 文字列への変換が生じますが、 これらの整形処理はどのタイミングで(あるいはどのように)行うべきでしょうか。 ・登録処理時:入荷日の整形 1. ボタンクリック時のイベントハンドラ btnSubmit_Clickで
のような形で取得、Date型に整形する 2. SQL記述前のinsertRecordメソッドで引数から整形する 3. ボタンクリック時のイベントハンドラ btnSubmit_Clickであらかじめ用意したGetterから取得する。
・照会処理時:分類コードの整形 1. getRecordメソッドにてDataSetを取得した後
2. GridView_RowDataBoundイベントメソッド等の割り当て時
3. SQLでの取得時にCASEを使って取得する
4. GridView_RowDataBoundイベントメソッド等の割り当て時。 ただし、あらかじめ用意したPropertyのGetterから取得する。 以上です。 個人的には3、4で、Proprertyを覚え立ての興味津々というのが丸分かりですが ![]() 当初得意になって、ページ内の全コントロールについてPropertyを作成したのですが、 ふと「本当にこれが正しいやり方なのか。本当に仕様変更に耐えられるのか」と疑心暗鬼になってしまいました。 .NETは導入したばかりで、誰も分からず周囲にOOPについて聞ける人もいません。 長文で申し訳ありませんが、上記の例以外でも結構ですので、ご意見をお願いします。 #ちなみに、長年無印ASPをやってきた同僚に意見を求めたところ1、1という答えが返ってきました。 | ||||||||||||||||||||
|
投稿日時: 2008-02-02 01:31
あくまで僕の場合ですが。
> ・登録処理時:入荷日の整形 まず1で書いて、その後可読性や重複の回避を考慮した結果3になったりします。 2はありえないです。GUIの都合をそこまで持ち込むのはよろしくないと思います。 > ・照会処理時:分類コードの整形 3はありえないです。GUIの都合をそこまで持ち込むのは(ry 1もあまりよろしくないですが、たまに1のようなことやって済ませたりします^^; 2と4はやったことないので僕には何とも言えないです。 普段(というほどこの手の経験ないですが)は、<%# 〜 %> と Eval を使って下記のように書いてます。
データ バインディング式の構文 _________________ C#と諸々 [ メッセージ編集済み 編集者: よこけん 編集日時 2008-02-02 01:38 ] | ||||||||||||||||||||
|
投稿日時: 2008-02-03 23:06
返答が遅くなり申し訳ありません。
まずDBに操作をかけるメソッドに整形処理を持ち込むのは100%誤りということですね。 また、Propertyでの整形/取得というのも、特に誤った方法ではないようで安心しました。 ><%# BunruiHelper.ConvertToDisplayText(CInt(Me.Eval("BunruiCD"))) %> このBunruiHelperというのは字義通り画面表示用に変換するヘルパークラスを 別途作成してということでしょうか。 上記のようなEvalに関数を組み合わせたバインド自体は使用したことがあったのですが、 恥ずかしながらヘルパークラスという発想には思い至りませんでした。 このクラスに画面表示の変換機能を集約させておけば、仮にDBのスキーマが変更になっても 直すのはこのクラスだけですみますね。合理的です。 しかし、とすると登録処理時の入荷日整形についても ヘルパークラスで対応したほうがわかりやすいような気もします。 …って、別クラスからはMe.txtYearという形でMeから取れないですね。 わざわざ取得してから整形ヘルパークラスに投げるというのは冗長ですし、 取得についてはPropertyで、設定についてはヘルパークラスという具合でやってみたいと思います。 (とはいえ、例にあげた程度の単純なものであれば、ダイレクトに変換しても問題ないでしょうけど ![]() 週末はOOP関連の書籍読み・サイト巡りで終わってしまいました。 ![]() これから現在の案件のUML作成にチャレンジしてみます。ご意見ありがとうございました。 |
1