以前に「1.5階層のAction-Service-Logicパターン」を紹介させて頂きました。今回は、このアーキテクチャにS2AbstractService を導入した場合のアーキテクチャについて検討してみました。 主な変更点として、S2AbstractService を導入する場合は、アクションやロジックから直接JdbcManagerを使うこと得策ではないと考え、データアクセスロジックは全てサービスを経由するようになった点です。 まずは、アーキテクチャを図示したものをご覧ください。細かい解説は別エントリにて書かせて頂きますが、エンティティ単位のサービスを採用しつつも、ユースケース固有のロジックはアクションに記述する方法を提示したいと思います。 アーキテクチャ（レイヤ構成図） アーキテクチャ（モジュール相関図）
趣旨とあんまり関係ないですが、Service・Logicをとりまぜた3階層にするならば、エンティティによったものをService、アクションによったものはLogicと呼んだ方が、フレームワーク側の呼び方との親和性は高いように思います。 ちなみに、今はこんな感じの設計はどうかと思っています。 Serviceクラス：エンティティと対につくる。ドメインモデル的な考え方がプロジェクト内でついていけないならばいっそのこと導入しない。 Logicクラス ・ユースケースを跨がる画面まわりの制御処理や、ユースケースをまたがるビジネスロジック特有の処理を書く。いわゆる、サブシステム間共通関数のイメージ。たとえば複数ユースケースであるケースでは沢山の表にインサートするが、あるケースではアップデートのみするようなものを使う。 ・ただし、Serviceクラス的設計が難しい場合には、画面制御的なクラス Servic
エンティティ固有のドメインロジックは別出しにします。 ひがさんが最近呼んでる「Service」に近いです。 でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。 そうでもないですよ。今、私が携わらせて頂いている案件では、 Action ： コントローラ Service： ユースケース単位のロジック + データアクセス Logic ： エンティティ単位のロジック + データアクセス ※ LogicはActionとServiceの両方から呼び出し可能とする。の方式に数人の中核のメンバーから納得感を得ています。 無難な選択肢だと思います。 一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。 この方式のポイン
セッションに格納したい場合は作る、っていうのがあれな気がします Struts に慣れている人に違和感がない気がします 最近よくあるフレームワークはプロパティも一緒に持ってるけど、あれはページ単位です サンプルでは小さいけど、実システムでは一緒にすると間違いなくでかくなります 誤解をおそれず古い言葉で言えば、トランザクションスクリプト最強です
SAStrutsのアーキテクチャにおいて、それぞれの処理をどのクラスに 記述するのが良いかの検討を引き続き行う。 下図はブラッシュアップした現時点での判断チャート。 順を追って説明してみる。 ユーティリィティ的な処理か？ 何を持ってユーティリィティ的な処理とみなすかは以外に難しい。 しかし、どのクラスに記述すべきかの見極め以前に、そもそも、 そのソースコードを書く必要があるかを疑ったほうがいい。 Apache CommonsやSeasar2のutilパッケージなど第三者が 作成したユーティリィティクラスでかなりの代替が利くはず。 プログラマ全員がプロジェクトの最初の段階で、 役立つ3rdパーティのユーティリィティ情報を共有しておくべし。 あとは、ユーティリィティ的な処理かどうかの見極めに 自信がない人は、センスのよさそうに相談するのが良い。 画面周りの処理か？ 画面周りのロジックの代表的な
「複数種類のエンティティを扱うロジックをどこに書くのか」、これは、非常に難しい問題です。エンティティに持たせると、どこのエンティティに持たせるのかを判断するのが難しい。 だから、アクションにもたせるのが良いと書いてきました。 でも、売上金額 = 売上明細.商品.単価 * 売上明細.数量みたいなロジックがあって、JSPに売上金額を表示する場合に、このロジックをアクションにもたせるかというと微妙ですね。 売上金額が1つしかないなら、それでもいいけど、複数あった場合は、うまくいかない。コメントで答えたように、これくらいの計算なら、ELでやっても全然いいんだけど、複雑な計算だとどうするのか。 売上明細エンティティが複数あって、複数の売上金額を表示するなら、売上エンティティで計算したほうが全然楽です。 <c:forEach var="e" items="salesDetailItems"> ${e.
1つユースケースに閉じていることは、すべてActionに記述し、複数のユースケースで使われるものをLogicに分割するのがシンプルでわかりやすいのではないかと、そう思ったわけです。 ＜＜中略＞＞ 追記2:コメントへの回答ですが、ユーティリティは、staticメソッドで構成されるやつは、utilのパッケージ。ActionにDIするやつは、logicパッケージでいいと思います。どっちでもないユーティリティもutilパッケージですね。 Entityについては、SAStrutsのドキュメントにもこのblogでも書いていますが、1つのEntityに閉じたロジックならEntityに記述するということでいいと思います。複数のユースケースで使うからこそ、Entityに書く意味がありますね。個別のユースケースでしか使わないなら、Actionに書いたほうがいいと思います。 上記のひがさんのエントリーを元に「ど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
