SAStrutsで二重サブミット防止
Teedaのダブルサブミットを調べついでにSAStrutsも。 SAStrutsの場合Tokenでチェックするみたいですねぇ。 そりゃそうか、Strutsだもんね。 チュートリアルのTokenActionをまるぱくり。 @Resource protected HttpServletRequest request; @Execute(validator = false) public String index() { TokenProcessor.getInstance().saveToken(request); return "index.jsp"; } @Execute(validator = false, validate = "validate", input = "index.jsp") public String result() { return "result.jsp"; }
Action-Service-Logic の3階層は冗長か？ - 出羽ブログ
エンティティ固有のドメインロジックは別出しにします。 ひがさんが最近呼んでる「Service」に近いです。 でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。 そうでもないですよ。今、私が携わらせて頂いている案件では、 Action ： コントローラ Service： ユースケース単位のロジック + データアクセス Logic ： エンティティ単位のロジック + データアクセス ※ LogicはActionとServiceの両方から呼び出し可能とする。の方式に数人の中核のメンバーから納得感を得ています。 無難な選択肢だと思います。 一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。 この方式のポイン
2008-05-08 - 出羽ブログ ～ はてな版 ～ スケールするアクション
特定のユースケースへの要件が少ない場合は、 ユースケースに対応した１つのActionクラスで基本的な処理は実装できます。 しかし、ユースケースへの要件が多い場合は、扱うクラスが増えてしまいます。 例えば、ユースケース専用のDto(ActionForm)やユースケース専用のLogic、セッション格納用Dtoなどです。 特定のユースケースに関するクラスが複数存在する場合は、 パッケージが分散しているよりも、１つのパッケージに集めた方が開発しやすいと思います。 (Teedaはこのような構成でした。) そこで、ユースケース名が "hoge" の場合、以下のような構成が可能なように SAStrutsを拡張してみました。 Java側： ＜ルートパッケージ＞.web.hoge.HogeAction.java ＜ルートパッケージ＞.web.hoge.HogeDto.java (ActionForm) ＜ル
2008-02-15
http://d.hatena.ne.jp/kwatch/20080215 いろんな意見があるもんだ。 でも、Struts 1.3.8って300Kもあったかなあ。 Maven2でWTP2.0対応のWebアプリのプロジェクトを生成し、SAStrutsのサンプルを のっけてみて、でついでにエラーをResourceSynchronizerで表示させるメモ。 http://d.hatena.ne.jp/higayasuo/20080214 http://d.hatena.ne.jp/taichitaichi/20080211/1202759047 つうかスゲー。 まず環境は下記のとおり。 maven 2.0.8 Eclipse eclipse-jee-europa-fall2-win32 JDK jdk1.5.0_09 Seasar 2.4.22 SAStruts 1.0.1-rc2 Resour
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
