続・S2JDBC の弱点を補完するS2AbstractService - 出羽ブログ
エンティティの結合を検索時に指定することがほとんどなので findByIdやfindAllなんかは実運用では出番があまりないかもです。 AbstractService に次のようなメソッドを用意すれば、結合も汎用的に扱うことができます。 AbstractService.java public class AbstractService<ENTITY> extends S2AbstractService<ENTITY> { public List<ENTITY> findAll(String leftOuterJoin, String orderBy) { return select().leftOuterJoin(leftOuterJoin) .orderBy(orderBy).getResultList(); } public ENTITY findById(Integer id, St
2008-07-07
エンティティの結合を検索時に指定することがほとんどなので findByIdやfindAllなんかは実運用では出番があまりないかもです。 AbstractService に次のようなメソッドを用意すれば、結合も汎用的に扱うことができます。 AbstractService.java public class AbstractService<ENTITY> extends S2AbstractService<ENTITY> { public List<ENTITY> findAll(String leftOuterJoin, String orderBy) { return select().leftOuterJoin(leftOuterJoin) .orderBy(orderBy).getResultList(); } public ENTITY findById(Integer id, St
S2JDBC の弱点を補完するS2AbstractService - 出羽ブログ
このエントリーではSeasar 2.4.26 から 導入された S2AbstractService について書かせて頂きます。S2AbstractService を活用することで、タイプセーフを保ちつつも、データアクセスロジック関連のソースコードを大幅に減らす効果が期待できます。 S2JDBC の弱点 S2JDBCを使えば、お手軽かつパワフルにデータアクセス処理が実現できます。しかし、生のS2JDBCを野放し状態に使った場合、プロジェクトの規模が少し大きくなると、ソースコードの重複を生みやすくなる問題に直面します。具体的に、次の１件分のデータ取得処理ですら、コピー＆ペーストされて複数箇所で使用されてしまいます。 Emp emp = jdbcManager.from(Emp.class).id(empId).getSingleResult(); 対処方法は、共通処理を抽出してメソッド化するこ
Strutsは古代、JSFは近代、現代はRails - ひがやすを技術ブログ
最近流行の古代、近代、現代パターンで、Webアプリケーションのアーキテクチャを振り返ってみたいと思います。 古代に生まれたStrutsですが、実は結構完成度が高く、WebにおけるMVCパターンは、Strutsでほぼ完成しています。ViewはJSP(Velocityもあり)とタグライブラリで決まり、ControllerもActionで決まり(StrutsそのものもControllerに分類する場合もあり)でしたが、モデルの実装方法は、決定的なものがありませんでした。 実は、モデルには、アプリケーションモデルとドメインモデルがありますが、この辺の考えも明確なものがありません。アプリケーションモデルという言葉は、あまり聞いたことがない方もいるかもしれませんが、SmalltalkのMVCは、既にそうなっているようです。 モデルをデータのみから成るドメインモデルと，アプリケーション固有の情報から成る
2008-06-26
趣旨とあんまり関係ないですが、Service・Logicをとりまぜた3階層にするならば、エンティティによったものをService、アクションによったものはLogicと呼んだ方が、フレームワーク側の呼び方との親和性は高いように思います。 ちなみに、今はこんな感じの設計はどうかと思っています。 Serviceクラス：エンティティと対につくる。ドメインモデル的な考え方がプロジェクト内でついていけないならばいっそのこと導入しない。 Logicクラス ・ユースケースを跨がる画面まわりの制御処理や、ユースケースをまたがるビジネスロジック特有の処理を書く。いわゆる、サブシステム間共通関数のイメージ。たとえば複数ユースケースであるケースでは沢山の表にインサートするが、あるケースではアップデートのみするようなものを使う。 ・ただし、Serviceクラス的設計が難しい場合には、画面制御的なクラス Servic
Action-Service-Logic の3階層は冗長か？ - 出羽ブログ
エンティティ固有のドメインロジックは別出しにします。 ひがさんが最近呼んでる「Service」に近いです。 でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。 そうでもないですよ。今、私が携わらせて頂いている案件では、 Action ： コントローラ Service： ユースケース単位のロジック + データアクセス Logic ： エンティティ単位のロジック + データアクセス ※ LogicはActionとServiceの両方から呼び出し可能とする。の方式に数人の中核のメンバーから納得感を得ています。 無難な選択肢だと思います。 一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。 この方式のポイン
2008-06-19
昨日、Firefox3が正式リリースされたのでインストールしてみました。 激速ですね。素晴らしい！キビキビしまくりです。 次世代ブラウザ Firefox http://mozilla.jp/firefox/ 今まで、WebブラウザはSafariを使っていたので、速さでは満足していました。でも「Googleツールバー」と「はてなバー」、「マウスゼスチャのプラグイン」が使えないことがやや不満でした。「Googleツールバー」で英単語にマウスフォーカスするとポップアップで日本語の意味を教えてくれる機能がないと、何気に英語の文章を読むのが辛かったんですよね〜。 SafariからFirefox3への移行において心残りなのは、Safariの美しいフォントから離れてしまうことです。 「Googleツールバー」以外のプラグインは、まだ確かめていませんが、これを機にメインで使うWebブラウザはFirefox
2008-06-17
『複数レコード処理（繰り返し）』の場合に、Entityをそのまま使うというのに違和感を感じてしまうのですが、そんな感覚にはこだわらない方が良いのでしょうか。 導出項目を得るような処理というのはプレゼンテーションロジックなのだから、DTOに値をコピーして、DTOのgetterで実装するようにした方が良いような気がしてしまっているのですが。 私の以前のエントリでは、繰り返し更新がなければDtoのではなく、Entityを積極的に使うことを書きました。でもDtoを使うケースでも特に問題ないと思います。ただし、メリット・デメリットは、把握しておいた方がいいと思います。 【メリット】 繰り返し処理には、常にDtoを使うため、設計に一貫性がでる。実装者も迷わない。 【デメリット】 プレゼンテーションモデル側で導出項目のロジックを用意すると重複しやすい。 繰り返し更新が必要となるケースは比較的少ない状況に
続・SAStruts + S2JDBCのアーキテクチャ 2008-06-06 - 出羽ブログ
ここで疑問点があります。この疑問点のため、眠れなくて早く起きてこのエントリを書いています。笑 ・ビジネスロジックをEntityとServiceに書く設計（最近流行のDDDの設計）だと思いますが、Entityのメソッドには、insertとかupdateとかdelete、かつエンティティ独自の振る舞いを持たせるServiceのメソッドには、findAllとかfindByNameとかというものが用意される認識で良いのか？ ・S2Daoを使用していた時は、１画面につき１Dtoを作って、そのDtoを画面表示に使っていました。 S2JDBCを使用すると、関連先のEntityが対象Entityにくっついて検索されるので、Entityを画面表示に使っても良い？ 画面表示用のDtoは不要？ 以下に、自分なり回答をさせて頂きますので、参考までにどうぞ。 まず、Entityのメソッドには、insertとかupd
SAStruts + S2JDBCのアーキテクチャを図示してみる - 出羽ブログ
SAStruts と S2JDBC を使って少し複雑なケースのWebアプリを開発する際において、現時点で自分が一番良いと考えているアーキテクチャを図示してみました。 なかなか良い感じです。あえて、課題をあげるならば、次の２点です。 アクションフォームの内部クラスに @Component(instance = InstanceType.SESSION) を付けて、スコープをセッションにしたいができないこと（やり方が分からないだけだと思う。）←できないことが判明しました ユースケースをまたいでアクションフォームを使用しない方針とした場合、検証メソッドをアクションフォームに書きたくなるが現状ではアクションにしか書けないこと。 追記： 1.0.3-rc1 より検証メソッドはアクションフォームに書くことができるようになります。 よって、検証メソッドはアクションからアクションフォームへ移すことをオスス
2008-04-17
1html = 1Page、ユースケース=ディレクトリ という分かりやすいTeedaのページ駆動開発をSAStrutsで挑戦してみました。 SASturtsの場合は、1html = 1Pageではなく、1JSP = 1Actionですね。 今回は、pageという名前のユースケースを想定してみました。 作成したモジュールは次のとおりです。 exercise.action.page.FromAction.java exercise.action.page.ToAction.java exercise.action.page.AbstractPageAction.java webapp/page/from.jsp webapp/page/to.jsp AbstractPageAction.java は pageユースケースのための FromActionとFromActionの共通親クラスです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
