08/08/21 23:34:15
訂正
×受信データを戻り値とする
○受信データを関数ポインタの引数にしてその関数を実行する
289:デフォルトの名無しさん
08/08/31 16:08:07
ちょっとここの主題とずれるかもしれませんが、
ブラウザ - Webサーバー - APサーバー - DB
という一般的な構成でのエラーチェックで質問です。
入力データのチェックをするときに、未入力や不正文字はMVCのCで
チェックして、DBに問い合わせないとわからないチェックはMでいいですよね。
注文入力をするときに、数量の未入力は前者、在庫チェックは後者です。
でですね、「数量の上限」や「不可能な注文の組み合わせ」みたいに
「ビジネスロジックだけどDBに問い合わせる必要はない」というチェックは
APになげると余計な通信が発生するのでWebサーバーでやろうと思ってます。
Webサーバー側のpackageには原則Actionクラスしかないのですが、
このpackage配下にチェッカークラスを置くのに違和感を感じます。
注文形態が複雑でActionがいっぱいあるので、注文BaseActionを
作ってTemplateMethodパターンでフローを決めてるのですが、
だらだらとバリデートを書くのもフローがわかりにくくなって嫌です。
注文クラスそのものに書くべき？
290:デフォルトの名無しさん
08/08/31 16:34:20
TemplateMethod 使ってるなら、BaseAction に空の Validate メソッド
用意してフローに組み込み、具体的なチェック内容は派生クラスで実装
すればいいんでないの?
なぜ「だらだら」になるかが知りたいところ。
291:デフォルトの名無しさん
08/08/31 16:49:46
そこまではやってるんだけど、さらにその中で「注文条件がこれだったら
これは不可で」「数量をparseして文字列だったらこのエラーメッセージで」
みたいな処理が10以上あって、ロジックは共通なので、その個別のValidateを
BaseActionに書いてたんです。個別Validateのどれを呼ぶかは
Actionによって異なります。で、このチェッカーって切り出すべきだと
思うんだけど、actionパッケージの下にチェッカークラス置くのって
変だよなーと思って相談したわけです。
292:デフォルトの名無しさん
08/08/31 16:50:33
だらだらなのはBaseActionに個別のValidate処理がいっぱい並んでたから。
わかりにくかったですね。すいません。
293:デフォルトの名無しさん
08/08/31 21:00:05
なんとなく状況は把握できた。俺なら BaseAction には単一の Validate
メソッドだけ用意し、チェックメソッドは別クラスにまとめる。たぶん、
このチェッカークラスは stateless になるんじゃないかな。
派生クラスではこのチェッカーを使って個々の Validate メソッドを実装
すれば良い。チェッカークラスの置き場所はまあ、プロジェクト的な決め事
でしょう。
294:デフォルトの名無しさん
08/09/01 00:26:21
そうなんだよね。
今は各Actionクラスの処理の切り出しのイメージだったから
個別ValidatorでsetFieldError()してるんだけど、チェック処理の
多さからいって全public staticなクラスに切り出すべきだと思ってる。
すでにリリースされてるプロジェクトの機能追加なのであまり
リファクタリングしたくないんだけど。
で、最初の質問に戻るんだってば。actionパッケージの下には
actionクラスしかなく、serviceパッケージの下にはリモート呼び出しを
前提としたクラスとそのドメインオブジェクトしかない。
今後のプロジェクトではserviceクラスのメソッドにアノテーションつけて
ローカル実行とリモート呼び出しを分けられるようにしようかと思っていた。
そうするとやっぱ今回もあるべき論的にはserviceパッケージの下に
ローカル実行用のサービスクラスをつくるのかな。でも単純な未入力チェック
みたいのはコントローラーでやるべきだと思うし、うーん。
295:デフォルトの名無しさん
08/09/01 00:42:31
やっぱり、どの個別Validatorを呼び出すかみたいなロジックが
Actionに入ってることがそもそもおかしい気がしてきた。
あ、いやでも注文形態によって入力パラメータの数が違うから
未入力チェックを行うならActionか。
もしかしてstrutsみたいに各フィールドのセッターでvalidationしよう
っていうのが間違っているのか？
Action -> 個別注文クラス生成 -> 個別注文クラス#Validate()呼び出し
→ OKならリモート注文ServiceのValidate()呼び出し
こうするとすごくスッキリする。略してスッキる。ActionはModelの
生成だけでロジックにはノータッチになるし。チェッカークラスが
複雑で外だしにするとしても、個別注文クラスと同じpackageに
いれればしっくりくる。略してしっくる。ドメインオブジェクトがアクセッサしか
持っていないようなドメインモデル貧血症なつくりにはしてないからね。
296:デフォルトの名無しさん
08/11/13 18:02:24
あげ
297:デフォルトの名無しさん
08/11/27 14:40:57
パブリックヘッダファイルとプライベートヘッダファイルの違いが分かりません、
パブリックヘッダファイルで提供する関数と内部で使う関数の分け方すらわかりません。
298:デフォルトの名無しさん
08/11/28 00:16:46
OOP以前の問題だな
299:デフォルトの名無しさん
08/11/28 00:39:31
パブリック複合
300:デフォルトの名無しさん
08/12/06 00:00:34
テンプレート・メソッド パターンの多階層継承はマジ勘弁。
追いづらい。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
BaseCollectLogic ← テンプレート・メソッド パターン
↑
FileBaseCollectLogic ← テンプレート・メソッド パターン
↑
DomainLogic
カスが
301:デフォルトの名無しさん
08/12/06 01:58:35
それはやりすぎというより、なんか設計がおかしい気がする。
302:デフォルトの名無しさん
08/12/06 06:03:41
エントリーポイントを増やすのが目的なんだろうけど、
うざったいってのはよく分かる。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
DomainLogic
としてBaseCollectとやらはコンポジションでもっとけと。
303:デフォルトの名無しさん
08/12/06 09:36:21
問題ない。次
304:デフォルトの名無しさん
08/12/06 19:23:37
IService はインターフェースで Run メソッドが定義されてる。
クライアントは、
DomainLogic dl = new DomainLogic();
dl.Run();
あれ？スーパークラス使わないの？
IService はどうした？
IService は？
カスが
305:デフォルトの名無しさん
08/12/06 19:26:08
>>304 は >>300 の続きね
306:デフォルトの名無しさん
08/12/06 19:33:02
で、お前ならどうしたいのよ
307:デフォルトの名無しさん
08/12/06 19:36:49
黙れカスが
308:デフォルトの名無しさん
08/12/06 19:48:28
で、お前ならどうしたいのよ