Goya
Pageクラスとは、HTML(JSP)と一対一に対応するクラスで、画面に関する情報とイベントを処理するロジックで構成されています。 HTMLの入出力項目がPageクラスのプロパティにボタンのクリックのイベントがPageクラスのメソッドに対応すると考えると分かりやす…
Seasar2.4では推奨のパッケージ構成があります。推奨のパッケージ構成を決めた理由は2つあります。 1つめは､プロジェクトのメンバの知識を共有すること。ある機能を持ったクラスは､どのパッケージに配置するのかあらかじめ決まっていると、直ぐに目的のクラ…
一般的なEJB3時代のアーキテクチャはType4で十分だと思います。でも、EJB3って開発が重いよね。修正するたびに、パッケージング化して、アプリケーションサーバにデプロイしないと、実際に動かしてみることできないって耐え切れない。 でも大丈夫。Seasar2で…
「Serviceに業務ロジックを書く」も「Entityに業務ロジックを書く」も結局問題を抱えています。それを解決するのがこのTypeになります。 Type4:EntityとEntityFacadeに業務ロジックを書く Entityに業務ロジックを書いた場合 業務ロジックで自分と関連の無いE…
「Type2:Serviceに業務ロジックを書く」でも、同じようなロジックが複数のViewに分散する問題は以前未解決のままです。それを解決しようとするのがこのTypeです。 Type3:Entityに業務ロジックを書く Viewごとに業務ロジックを書けば､分散してしまう可能性が…
Type2:Serviceに業務ロジックを書く ManagedBeanに業務ロジックを書くパターンの問題点である「クラスが肥大化してメンテナンスが困難になる」を解決するのが､このTypeで、Actionから業務ロジックを分離して、Serviceで業務ロジックを実装します。ServiceはA…
EJB3、JSF、JPAを使ったときに業務ロジックはどのように実装すればよいのでしょうか。 Type1:ManagedBeanに業務ロジックを書く 最初は、ManagedBean(多くの場合Action)に業務ロジックを書くパターンです。 TransactionServletFilter Action(プレゼンテーショ…
EJB3、JSF、JPAを使ったときのアーキテクチャは､ある一定のパターンで説明できると思っています。私見ですが､説明したいと思います。 まず、プレゼンテーション層であるJSFですが、ページ(View)ごとにManagedBean(s)を定義します。ManagedBeanの作り方は3パ…
それは、ブラウザからアップロードされたファイルの保存をどこで、実装させるかということです。 ファイルの保存は､プレゼンテーション層のHelperロジックなので､それ用のコンポーネントを作り､ActionにDIします。なぜ、Serviceでやらないかというと、トラン…
一方で、DB設計があってUIがあって、そこで初めて取次ぎ役であるクラス設計に入るというのは、これは貧血症だなんだと言われるパターンで、OOな世界でも異教徒です。 DB設計から入るから､貧血症になるということは､特に無いと思っています。ドメインモデル貧…
s2jsfをいろいろ見てるんだが、actionとlogicの役割を分ける必要って実際のところあるんだろうか？ と激しく疑問。 この話は、S2JSFというより、goyaの話になりそうですが、Actionはプレゼンテーション層のクラスであり、Logicはビジネスロジック層のクラス…
モデルは、その使われる場所によって、プレゼンテーションモデル、ドメインモデル、ERモデル(RDBMSの場合)に分かれます。プレゼンテーションモデルはプレゼンテーション層で使われ、ドメインモデルはビジネスロジック層で使われ、ERモデルはリソース層で主に…
http://d.hatena.ne.jp/higayasuo/20050825#1124957707で書いたActionとServiceの統合ですが、いろいろ考えてみましたがActionの責務が多いと思うので、やはりActionとServiceは分離すべきだと思います。 そもそもこの話は、Dxoをどこに置くべきかの話だった…
http://d.hatena.ne.jp/bakock/20050824#p1 画面にはドメインオブジェクトを渡す派は、本来のOOP的な考えにマッチしてるように思える。ドメインのモデルをどう整形して表示してるか、ソースに直接書いてあって、トレーサビリティが高い。凝集度が高いといっ…
ここでの仕様変更とは、仕様追加も含むこととします。そうすると、アジャイルだとかウォーターフォールだとかに関係なく、開発のかなりの部分は仕様変更による対応で占められることになります。仕様変更に対し、いかに容易に対応するのかがポイントになって…
Actionをプレゼンテーション層とビジネスロジック層のglueとして使う場合、レイヤとしては、プレゼンテーション層とビジネスロジック層の2層構造になります。データアクセス層はDaoとしてビジネスロジック層に吸収します。ActionからDaoを呼び出す場合もある…
これまで、Actionはプレゼンテーション層のコントローラ(コマンド)であり、Serviceはビジネスロジック層のコントローラ(ファザード)という話をしてきました。ActionはプレゼンテーションモデルをServiceに渡し、ServiceはDxoを使って、プレゼンテーションモ…
プレゼンテーションモデルとドメインモデルをどこで変換したらよいのかは難しい問題です。私は、ビジネスロジック層で変換したほうが良いと考えていますが、その理由は2つあります。 1つは、チームに必要とされる知識と開発者のレベルです。 一般にプレゼン…
ビジネスロジック層は次のようなクラス(アプリケーションロジックもドメインロジックも1つのクラス)で構成されます。 サービス Dxo アプリケーションロジック メールを送るなどドメインに無関係なロジック ドメインモデルの再利用性を高めるためドメインモデ…
レイヤアーキテクチャの場合、ある層は、自分の直接下位の層にのみ依存し、それ以外の層には依存しないのが基本です。通信は、下位の層とデータをやり取りすることで行います。 それでは、このデータはどの層に属するのでしょうか。層に属することにすると、…
アプリケーションをレイヤ分割した場合、 プレゼンテーション層 -> ビジネスロジック層 -> データアクセス層 のように分けるのが一般的ではないかと思います。 ここで、矢印は、依存関係を表しています。例えば、プレゼンテーション層は、ビジネスロジック層…
DIでインジェクションされるオブジェクトの型にインターフェースを使うのは、実装が変わったときでも、利用者側に影響を及ぼさないようにするためです。この辺の詳細は、JavaWorld8月号のDIとOCPのところで触れています。 逆にスクリプト言語で型を意識する…
リッチなドメインモデルのアンチパターンの1つとして、「ホットスポットを考慮せずに関連のあるデータと振る舞いを1つのクラスに詰め込んだもの」があります。 このパターンは、変更による影響を受けやすいので、変更の多いシステムには、向いていません。逆…
ホットスポット(変更の起きそうな部分)を分離する。 これは、変更に強いシステムを作る上での最も基本的な原則です。例えば、あるクラスが安定している部分と、頻繁に変更される部分で構成されていたとします。このクラスに変更が入るたびに、安定している部…
http://d.hatena.ne.jp/habuakihiro/20050705#1120560197 ということで、新設計手法として、Goyaを誕生させました。 これからは、設計手法もオープンソース的なアプローチで、いろいろなフィードバックを受けながら、常に進化しつづける必要があると思うので…
