Private content!This content has been marked as private by the uploader.
Private Presentation
Private content!This content has been marked as private by the uploader.
Teedaでの開発ポリシー - akiraneko’s blog
私が思っている小規模から中規模向けのTeeda開発ポリシーです。 大規模はそもそもSAStrutsを（あわわ） 前提の前提 オフィシャルサイトの『現場で役立つ実践Teeda』（http://teeda.seasar.org/ja/presentations.html）が標準的な開発環境をきれいに記述しているドキュメントになります。 全体的にここのプレゼンテーション資料は非常に質が高いので、すべて目を通しましょう！ 前提 データベース周りの処理はDBAが担当、ロジックはロジック専用の人が担当、画面は画面専用の人が担当っていう階層わけした開発用ではありません。機能ごとでの分担を前提としています。 また、デザインパターンを意識しないでいます。そもそもデザインパターンは作っていて問題がでたから導入する流れが好ましいと思っているので、無駄に複雑なデザインパターンありきで実装をするのもどうかと思ってい
ひがさんのBlogのまとめサイト - 豆無日記
こんなすばらしいまとめサイトがいまだかつてあっただろうか。 という感動の渦の中、一気読み。 wikiroom.com 閉鎖 自分用に、感銘を受けたところ、疑問点などポイントをピックアップしてまとめておこうと。引用先の改行とかスタイルとかは適宜修正してます。 なんか、 すでにお前のいる場所は我々は1年前に通過しているッ という感じで、ここ最近悩んでることとか、すでに議論されつくしている感が満載で、ワタクシちょっと非常にあせっております。 どの記事も内容が濃い上に記事の数が半端ではないため、まずはくーす時代の記事について追っかけてみます。 例外 catch禁止。間違いない。 2004-06-08 - ひがやすを blog うおお。強気だ。断言だ。 そうか、やっぱり最近のダイコン時代の流れはそうなっていくんですねぇ。 原則実行時例外ってのも結構衝撃でした。 「例外をキャッチしてすぐロギング」とい
続・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(); 対処方法は、共通処理を抽出してメソッド化するこ
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 より検証メソッドはアクションフォームに書くことができるようになります。 よって、検証メソッドはアクションからアクションフォームへ移すことをオスス
日米トップJ2EEアーキテクトが語るフレームワークの未来---Gavin King氏にひがやすを氏が聞く
O/Rマッピング・ツールHibernate，JBossのフレームワークSeamの作者Gavin King氏。King氏はEJBなどJavaのコンポーネントを統合するWeb Beansを提唱し，Javaの標準化プロセスである「The Java Community Process」で標準化が行われている。金融業のシステムや商用フレームワークに採用されているDI(Dependency Injection）コンテナSeasar2の作者ひがやすを氏。ひが氏はSeasar2で，アジャイルな開発を実現するためのツール作成に取り組んでいる。日米のトップJ2EE(Java2 Enterprise Edition)フレームワーク・アーキテクトがWebアプリケーション・フレームワークの未来について語った。
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の共通親クラスです。
2007-10-29 - ひがやすを blog - ERモデルとドメインモデル
エンティティのマッピングで、S2JDBCがJPAと違っているところは、外部キーのプロパティを必要とすることです。 これは、S2JDBCとJPAの根本的なモデリングに対する考えの違いからきています。 S2JDBCは、ERモデルをエンティティに忠実に反映させるという考えです。だから、テーブルのカラムは、エンティティと一対一に対応させます。 それに対しJPAは、ドメインモデルとERモデルを別途作成し、それをO/R Mappingしていきます。重要なのは、ドメインモデルなので、ドメインモデル上必要のない、外部キーに対するプロパティはいらないのです。 どっちがいいのかは、好みの問題ですが、個人的には、ドメインモデルとERモデルという、似てそうで、分析手法が違う2つのモデルを作成するより、ERモデル1つの設計で済ませるほうが楽なので好みです。 データの入れ物にRDBMSを使っているんだから、RDBMS
Teeda で Service を使う際の方針（その３） - 出羽ブログ
[seasar]Teeda で Service を使う際の方針（その３）です。 たぶん、迷っているってことは、どれも決定的ではないということなはず。6/29にも説明するつもりですが、私の考えは次のとおりです。 ひがやすを blog - [Seasar]Service を使う際の方針 ひがさんがトラックバックで私の疑問に対するblogエントリーを書いてくれました。 なるほど、考え抜かれたシンプルさを感じます。 一見、なんてことの無いように思えるが、次の重複したロジックを親クラスに持っていく発想が特に気に入りました。 同一ユースケース(サブアプリケーション)の複数の画面で使われるロジックは、各画面の共通の親Pageクラスに持たせる。 重複が見られた時に、どこにコードを記述すべきか分かりにくかったり、面倒だったりすると、確信犯的にコピ＆ペーストする人が実際には多い。なので、重複対策は、うるさいほ
Teeda で Service を使う際の方針（その２） - 出羽ブログ
Teeda で Service を使う際の方針について、チャットとか含めて多くの意見を頂いたので一度、論点を整理してみました。 １．そもそもServiceは使うべきか？ A. 使う B. 使わない C. ある条件下で使う D. 分からない ２．Serviceメソッドの引数にPageを使う是非について A. Pageを使うのはOK B. Pageを使うのはNG C. 分からない ３．Serviceの粒度について A. Pageごと B. SubApplicationごと C. 分からない ４．Serviceにインターフェースは必要か？ A. 必要 B. 不要 C. 分からない ５．Dxoの呼び出し場所 A. Page B. Service C. PageとServiceのどちらでもOK D. 分からない ちなみに、現時点での私の考えは次の通りです。 1-D 正直、これは迷っています。 2-A
Teeda で Service を使う際の方針 - 出羽ブログ
TeedaでService を使う場合で、以下のどちらの案が良いか迷っています。 案１：Serviceメソッドの引数が増えた場合に、Pageクラスを引数にする方法 【特徴】 DxoはPageとServiceの両方で使うことができる 更新系は、Serviceメソッド内でDxoを呼び出してEntityを取得する 参照系は、Serviceメソッドの戻り値に対してDxoする Serviceメソッドの引数にEntityは用いない 【メリット】 Serviceメソッドの引数がPageに統一されてシンプル 【デメリット】 更新系の場合、Serviceメソッド内でDxoしてEntityを取得することになる。一方、参照系の場合のServiceメソッドの戻り値をEntityとするとPageクラス内でDxoすることになる。このような場合だと、１つ１つの処理はシンプルであるが、Dxoによるデータ変換処理がPage
ひがやすを blog - [Seasar]Service を使う際の方針
6/29 19:00から21:00 wakhokの12FでSeasar2のmini eventを行います。協賛は、日本Javaユーザグループです。 場所はこちら。 http://www.wakhok.ac.jp/tyo-sat/map.html 場所を貸していただくwakhokのみなさまありがとうございます。 うわさのtugboat.GTDが登場します。 http://tugboat-gtd.sandbox.seasar.org/index.html ぜひ、screenshotやデモをお試しください。 イベントの内容はこちら。 Seasar2の実装事例 - tugboat.GTDの紹介 tugboat.GTDの紹介/デモ version 0.8 Preview: tugboat.GTD + RESTful WEB Services. Super Agile Web Development
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユースケースと継承と委譲と… - ようじのにっき