[seasar]Teeda で Service を使う際の方針(その3)です。 たぶん、迷っているってことは、どれも決定的ではないということなはず。6/29にも説明するつもりですが、私の考えは次のとおりです。 ひがやすを blog - [Seasar]Service を使う際の方針 ひがさんがトラックバックで私の疑問に対するblogエントリーを書いてくれました。 なるほど、考え抜かれたシンプルさを感じます。 一見、なんてことの無いように思えるが、次の重複したロジックを親クラスに持っていく発想が特に気に入りました。 同一ユースケース(サブアプリケーション)の複数の画面で使われるロジックは、各画面の共通の親Pageクラスに持たせる。 重複が見られた時に、どこにコードを記述すべきか分かりにくかったり、面倒だったりすると、確信犯的にコピ&ペーストする人が実際には多い。なので、重複対策は、うるさいほ
Teeda で Service を使う際の方針について、チャットとか含めて多くの意見を頂いたので一度、論点を整理してみました。 1.そもそもServiceは使うべきか? A. 使う B. 使わない C. ある条件下で使う D. 分からない 2.Serviceメソッドの引数にPageを使う是非について A. Pageを使うのはOK B. Pageを使うのはNG C. 分からない 3.Serviceの粒度について A. Pageごと B. SubApplicationごと C. 分からない 4.Serviceにインターフェースは必要か? A. 必要 B. 不要 C. 分からない 5.Dxoの呼び出し場所 A. Page B. Service C. PageとServiceのどちらでもOK D. 分からない ちなみに、現時点での私の考えは次の通りです。 1-D 正直、これは迷っています。 2-A
TeedaでService を使う場合で、以下のどちらの案が良いか迷っています。 案1:Serviceメソッドの引数が増えた場合に、Pageクラスを引数にする方法 【特徴】 DxoはPageとServiceの両方で使うことができる 更新系は、Serviceメソッド内でDxoを呼び出してEntityを取得する 参照系は、Serviceメソッドの戻り値に対してDxoする Serviceメソッドの引数にEntityは用いない 【メリット】 Serviceメソッドの引数がPageに統一されてシンプル 【デメリット】 更新系の場合、Serviceメソッド内でDxoしてEntityを取得することになる。一方、参照系の場合のServiceメソッドの戻り値をEntityとするとPageクラス内でDxoすることになる。このような場合だと、1つ1つの処理はシンプルであるが、Dxoによるデータ変換処理がPage
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト AOPの適用は、自分でも何となくやってしまっているところがあり、設計手法として改めて考えてみると、説明が難しいところがあります。 今回は、自分なりの考えをまとめてみます。 AOPをどこに適用すれば良いのか? 「AOPとは何か?」って聞かれたら答えやすいのですが、「AOPをどこに適用すれば良いのか?」と聞かれると、答えるのが難しいですね・・・。 自分で設計していても、感覚的に決めてしまっているように思います。 AOPの例として、トランザクションやロギング処理が良く取り上げられるますが、それらはシステム全体としては、どのように位置づけられるのでしょうか? システムとして、ユーザに適用する機能(core concern)とAOPで実現する機能(crosscutting concern)は、縦横のような関連を持
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト 今回は、Pageクラスの継承についてです。 Pageの継承 現在のTeedaのバージョン(3/18現在 Ver.1.0.6)では、各画面のPageクラスは、基底となる独自のPageクラスを継承するようにしておくと便利です。 多くのWebアプリケーションでは、以下のようにしておくと良いと思います。 AbstractBasePage アプリケーション全体の基底クラス AbstractSubAppPage サブアプリケーションの基底クラス SubAppXxxPage 個々のPageクラス 上記の継承関係にした場合、バリデーションには注意する必要があります。 親クラスのバリデーションは継承されません。小クラスで明示的に指定する必要があります。 #バリデーションの継承を行えるようにするのは、現在Teedaコミッタ
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト 工程の位置づけ システムがユーザに提供するものを定義します。 システムの振る舞いとして、ユーザレビューを行うもの 内部設計以降の工程でプロジェクトメンバが増えることを前提として、インプットとして決定しておくべきもの という観点で、標準(?)のGoyaでは含まれていませんが、DB設計もこの工程に含めています。 成果物 業務機能一覧 業務ごとに、システムの役割の概要を書く。 画面遷移図 業務フローから、画面遷移図を書き起こす。 UIスケッチ 画面の構成を決定する。入力/表示項目、ボタン/リンクのみを記述し、デザインにはこだわらないように注意する。 業務フローに沿って、ウォークスルーを実施。漏れ/不要/修正箇所を洗い出す。 画面項目説明 項目の仕様として、説明/初期値/バリデーションルールなどを記述します。D
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト 普段使用されている手法で問題ありませんが、Teeda Extensionの強み/弱みを知らないと、後で苦労することになると思いますので、ここでは、その点について紹介したいと思います。 また、一般の要件定義レベルよりは、後工程でのリスクを軽減するためにも、実装に近いレベルで書きたいと思います。 ※2007/02/11時点 Teeda Extensionの特徴 JSF拡張 JSFの仕様をベースに、JSFの使いづらい点を拡張したフレームワーク。 ページ駆動開発 HTML画面を起点に開発を実施する。画面とそれに関連するデータや処理を、1対1で開発するスタイルを採用しており、画面と画面遷移のアンマッチを解消している。 HTMLテンプレート Viewのテンプレートを標準的なHTMLだけで記述することが可能。これまで
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト 今回はアーキテクチャについてです。 レイヤー構成について、3パターンほど私が考える案を紹介します。 各コンポーネントの役割については、別途説明したいと思います。 Full Pattern 特徴 大規模アプリケーション向け。 コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。 Serivceがトランザクション境界となる。 レイヤー構成 プレゼンテーション層 Action、Page、Dto サービス層 Service、Dxo ドメイン層 Logic、Dao、Entity Middle Pattern 特徴 中規模アプリケーション向け。 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く