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
2007-06-08
Seasar mini event http://d.hatena.ne.jp/higayasuo/20070606#1181103955 http://quote.yahoo.co.jp/q?s=3850.t&d=t おめでとうございます。 誤解が無いように注意がいる箇所として、重複部分の全ては継承と述べているのではないです。次のように、委譲モデルも併用しています。 複数のユースケースで使われるロジックは、共通のユースケースを抽出し、共通のユースケース名Serviceクラスに持たせる。 なんとなく、このような設計にした方が良いとは思いますが、なぜ、上記のような局面において、継承モデルではなく、委譲モデルを採用したのか理由が気になるところです。 私は、単にシンプルさを求めるだけではなく、複数の人で並行で開発しやすいということも常に重視しています。一つのユースケースは一人で開発することが多い
ひがやすを 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
PHP at Yahoo!を読む - Sooey
PHP at Yahoo!を読む イタリアで開催されたPHPDay 2007にてYahoo! EuropeのFederico Feroldi氏が行なった「PHP at Yahoo!」のプレゼン資料が、氏のブログで公開されました。 Yahoo!が社内でどのようにPHPを使用しているのかということはこれまでにもRasmus Lerdorf氏のプレゼンなどで明らかにされてきましたので、「PHPのビルド時にはモジュールはほとんど組み込まない」とか「ビジネスロジックをエクステンションとして実装する」といったことは皆さんご存知だと思います。今回も前半はそんな感じの内容ですが、途中で実装よりの具体的な話題になってきたと思ったら、Yahoo!が利用しているテンプレートエンジン r3がオープンソース化したと書かれていてビックリ。しかもsymfonyのビュー層にも組み込んで使っているとか。 他にもDrupal
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～内部設計【AOPの適用】～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト AOPの適用は、自分でも何となくやってしまっているところがあり、設計手法として改めて考えてみると、説明が難しいところがあります。 今回は、自分なりの考えをまとめてみます。 AOPをどこに適用すれば良いのか？ 「AOPとは何か？」って聞かれたら答えやすいのですが、「AOPをどこに適用すれば良いのか？」と聞かれると、答えるのが難しいですね・・・。 自分で設計していても、感覚的に決めてしまっているように思います。 AOPの例として、トランザクションやロギング処理が良く取り上げられるますが、それらはシステム全体としては、どのように位置づけられるのでしょうか？ システムとして、ユーザに適用する機能（core concern）とAOPで実現する機能（crosscutting concern）は、縦横のような関連を持
【ハウツー】クラス構造がまる見えに! UDocでJavaをダイナミックに分析する (1) Ja...
UML、なかでもクラス図はクラスの関係を把握するうえで欠かせないダイアグラムだ。できれば既存のAPIはクラス図を見て簡単に全容を把握しておきたい。その際に全自動でクラス図を作成できると大変便利だろう。そこで紹介したいのがUDocだ。こうした用途にぴったりのアプリケーションである。 UDocはJava クラスをUMLライクのダイアグラムによって視覚化するGUIアプリケーションだ。Javadoc、Javaバイナリファイル、Javaソースコードなどから動的に UMLライクのダイアグラムを生成できる。生成されるダイアグラムそのものを動的に編集することも可能なので、グリグリといぢりながらクラス関係を解析できるすぐれものだ。動作にはJDK 5.0かそれ以上のバージョンが必要。本稿執筆時点の最新版は12日(米国時間)に公開された1.005であり、GNU GENERAL PUBLIC LICENSE Ve
Teeda Extension featuring Goya 〜アーキテクチャ【Pegeの継承】〜 - 現場のためのソフトウェア開発プロセス - たかのり日記
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回は、Pageクラスの継承についてです。 Pageの継承 現在のTeedaのバージョン（3/18現在 Ver.1.0.6）では、各画面のPageクラスは、基底となる独自のPageクラスを継承するようにしておくと便利です。 多くのWebアプリケーションでは、以下のようにしておくと良いと思います。 AbstractBasePage アプリケーション全体の基底クラス AbstractSubAppPage サブアプリケーションの基底クラス SubAppXxxPage 個々のPageクラス 上記の継承関係にした場合、バリデーションには注意する必要があります。 親クラスのバリデーションは継承されません。小クラスで明示的に指定する必要があります。 #バリデーションの継承を行えるようにするのは、現在Teedaコミッタ
10のアプリケーションロールパターン ― ＠IT
インタラクションデザインパターン（2） アプリケーションロールデザイン、 基礎の10パターン ソシオメディア 上野 学 2007/3/19 前回の「80年代のAppleに学ぶUIの部品化とガイドライン」では、インタラクションデザインの作業にパターンを活用することの有用性について説明しましたが、今回からは、実際にどのようなデザインパターンがあるのかを考えていきたいと思います。 私はこれまでの連載（ユーザビリティのヒント、Webアプリケーションのユーザーインターフェイス）を通して、インタラクションやユーザーインターフェイスのデザインはプログラムが出来上がってしまってから最後に付け加えるというものではなく、システムの基本的な品質を決定する重要な要素として設計の初期段階から考えなければならないものであると主張してきました。なぜなら、そのシステムが提供しようとしている機能を、画面の見た目や操作の流れ
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～外部設計～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 工程の位置づけ システムがユーザに提供するものを定義します。 システムの振る舞いとして、ユーザレビューを行うもの 内部設計以降の工程でプロジェクトメンバが増えることを前提として、インプットとして決定しておくべきもの という観点で、標準（？）のGoyaでは含まれていませんが、DB設計もこの工程に含めています。 成果物 業務機能一覧 業務ごとに、システムの役割の概要を書く。 画面遷移図 業務フローから、画面遷移図を書き起こす。 UIスケッチ 画面の構成を決定する。入力／表示項目、ボタン／リンクのみを記述し、デザインにはこだわらないように注意する。 業務フローに沿って、ウォークスルーを実施。漏れ／不要／修正箇所を洗い出す。 画面項目説明 項目の仕様として、説明／初期値／バリデーションルールなどを記述します。D
![たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～外部設計～](https://cdn-ak-scissors.b.st-hatena.com/image/square/25e7558323c09b52d06cb979120703dc35339b82/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F6435988827677137249%2F11696248318753705804%2F1369152372)
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～要件定義～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 普段使用されている手法で問題ありませんが、Teeda Extensionの強み／弱みを知らないと、後で苦労することになると思いますので、ここでは、その点について紹介したいと思います。 また、一般の要件定義レベルよりは、後工程でのリスクを軽減するためにも、実装に近いレベルで書きたいと思います。 ※2007/02/11時点 Teeda Extensionの特徴 JSF拡張 JSFの仕様をベースに、JSFの使いづらい点を拡張したフレームワーク。 ページ駆動開発 HTML画面を起点に開発を実施する。画面とそれに関連するデータや処理を、1対1で開発するスタイルを採用しており、画面と画面遷移のアンマッチを解消している。 HTMLテンプレート Viewのテンプレートを標準的なHTMLだけで記述することが可能。これまで
たかのり日記 Teeda Extension featuring Goya ～アーキテクチャ【レイヤー構成】～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回はアーキテクチャについてです。 レイヤー構成について、3パターンほど私が考える案を紹介します。 各コンポーネントの役割については、別途説明したいと思います。 Full Pattern 特徴 大規模アプリケーション向け。 コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。 Serivceがトランザクション境界となる。 レイヤー構成 プレゼンテーション層 Action、Page、Dto サービス層 Service、Dxo ドメイン層 Logic、Dao、Entity Middle Pattern 特徴 中規模アプリケーション向け。 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、
Teeda Extension featuring Goya 〜アーキテクチャ【コンポーネント】〜 - 現場のためのソフトウェア開発プロセス - たかのり日記
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回は、各コンポーネントの役割についてです。 Action 役割 プレゼンテーションロジック。画面項目の表示／非表示切替や、ボタンを押下したときの処理などを記述する。 インプット 操作シナリオ 作成単位 画面単位 命名ルール 画面名+Action（例:EmpListAction） Teedaのルール上、ボタンに付けたid（do〜）がメソッド名となります。 初期化メソッドは、initialize/prerenderとなる。前者は、画面が表示される最初の1回だけ呼び出され、後者は、画面表示の度（バリデーションエラー時やポストバック時など）に呼び出されます。 Page 役割 プレゼンテーションモデル。Actionと分離しない場合は、プレゼンテーションロジックも兼ねることになる。画面項目と1対1のプロパティを持
「ソフトウェアの仕様書は料理のレシピに似ている」へのフィードバックをいくつか集めてみた
一年近く前に書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリー。今になってもトラックバックやコメントが送られて来るのは、実際に日本のIT業界に働く人たちの間にも「今のやりかたはおかしい」という疑問や不満があるという証拠だろう。 そこで今日は、シオレットの引用機能のテストも兼ねて、よせられたフィードバックを新しい順にいくつか紹介してみる（それも、昨日になってやっとシオレットが動き始めたSafariブラウザーを使っての投稿だ^^）。 まして、優秀でないエンジニアがコードを書かずして、仕様書を作ることが出来ようか？ソフトウェア開発はウォーターフォールでは上手くいきません。 【さくねこの”チラシうら”にっきより引用】 別会社のSEが設計して、それを請け負った会社のPGが実装する。こんなやり方でまともなプログラムが作れたらある意味凄い。物凄いオーバーヘッド作業をこなして作るわけだ
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート
先週末に予定されていたJTPA企画の梅田さん主催オンラインサロンですが、会場に多くの人が集まるにつれてLingrが重くなってしまうという事態に陥ってしまい、まるでイベントの体をなさないまま時間が過ぎてしまい、あえなく中止となってしまいました。 当イベントを楽しみにしていた皆様、そして梅田さんはじめJTPAスタッフの方々には、本当に申し訳なかったと思います。ここに改めてお詫び申し上げます。 Macworld 2007のときには180人を収容して何の問題もなく快適に使えていたので、「1000人はわからないけど、200人ぐらいなら大丈夫だろう」とたかをくくっていたのが間違いでした。 今回はその反省も含めて、内部で検証した技術情報をすべて公開し、どのような問題に直面し、どのように解決にあたっているのかをお伝えすることで、特に技術者の皆さんに役立つフィードバックにしたいと思います。 ■今回のアーキテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
eBayのアーキテクチャ - 設計と実装の狭間で。
スカイプの技術的な仕組みについて教えてください。…
バックナンバー – おくvillage
Technologies for UI