- PR -

ビジネスロジックの切り出し

1
投稿者投稿内容
なぁ
会議室デビュー日: 2007/01/26
投稿数: 2
投稿日時: 2007-01-26 15:23
はじめて質問させていただきます。

ビジネスロジックの切り出しについて悩んでいます。
StrutsのActionクラスはビジネスロジックを書くところと説明(記事)を読んだのですが、一方でActionに全てのビジネスロジックを書くと保守性が悪いとも説明も読みました。
そこでビジネスロジックを切り出して保守性を高めるということは分かるのですが、単純にビジネスロジック部分を別クラスに書いて、Actionクラス上で"new"すれば切り出したことになるのでしょうか？

よろしくお願いします。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2007-01-26 16:00
どこにビジネスロジックを書くかどうかは宗教みたいなものでどれが正しいってことはないと思います。
EJB の SessionBean に書くのでも、POJO に書いて自分で new するのも、POJO に書いて Spring とかに生成を任せるのもどれも正解です。

とりあえず現時点で必要性を感じないのであれば Action クラスに書いてしまうのもアリです。
ユニットテストがちょっと面倒になりますが StrutsTestCaseとか使えばそれほど問題ではないでしょう。
taku
ぬし
会議室デビュー日: 2002/11/12
投稿数: 918
お住まい・勤務地: 墨田区→中野区
投稿日時: 2007-01-26 16:02
　Strustのアクションクラスの役割はコントローラーです。
ビジネスロジックはJavaBeans若しくはＥＪＢに記述します。
ＭＶＣモデルはご存知ですよね？
というかStrutsの基本書やJ2EEの基本書をまず読んでから質問なさい。
インターネットで済ますなんて論外です。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2007-01-26 16:16
るぱんです。

そもそも論からすれば、
ＭＶＣではＭodelにBusinessLogic（以下BL）を記述すると言う慣わしです。
JavaBeansの変遷も視野に入れてみると、
そもそも、JavaBeansはAccesser（setter、getter）とActionMethod（Accesser以外）があり、
ActionMethodにBLを記述しよう・・・と言うお題目がありました。
しかし、仕様の変更に対する柔軟性の確保と堅牢性の維持を目的に、
BLをクラスとして外に出してしまい、引数にBeansを使うと言う発想の転換が行われました。

Strutsの場合、Controllerはstruts-config.xmlであり、
強いてあげるのであれば、DespatchActionまでがControllerとみなしてよいと思います。
Actionそのものは、その名前の通り、Actionなので、ボタンアクションと意識する人が多いと思います。

BLにデータの塊の移行を記述するのは美しくないので、
Actionクラスには、BeanUtils等を使ってデータの移行を行う・・・と言ったお題目もあったと思います。

Actionクラスからnewして呼び出すのが一般的な様に思います。
その呼び出し先がsession beanでも、自作BLでも構わないと思います。

ビジネスロジックの切り出しと言うから、
要件からビジネスロジックの切り出しかと思ってしまった僕は
頭悪いですかね・・？？汗

要件からビジネスロジックがちゃんと切り出されてれば、
それほど悩む話ではないと思うのですが・・・？
切り出されていなければ、上流行程が破綻してるのでは・・・？
なぁ
会議室デビュー日: 2007/01/26
投稿数: 2
投稿日時: 2007-01-26 16:27
インギさん、takuさん、るぱんさん
すばやい回答ありがとうございます。

ビジネスロジックからのDBへのアクセスする時は、懸命に"new"をなくそうとしているイメージがあったものですから、"層"をまたぐ時は"new"するのが正しいのかどうしてもイメージが掴めなかった為質問させていただきました。

EJBなど使うものは別にして、何かしらの形で"new"するということで理解しました。

ありがとうございます。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2007-01-26 16:47
るぱんです。

レイヤーをまたぐ話と、
newする／しない話は、二アリーイコールだとは思うけど、別物です。

何故、「ビジネスロジックからのDBへのアクセスする時は、懸命に"new"をなくそうとしている」のか、そこが問題なんだと思いますよ？

new をなくすと、どういったメリットが得られるのでしょう？

[ メッセージ編集済み 編集者: るぱん 編集日時 2007-01-26 16:57 ]
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-01-26 17:44
業務ロジックを切り分けるときの私なりの基準ですが、

「スタンドアロンアプリでもWebアプリでもどっちでも使えるか。」

を基準にすることが多いです。
Webであるがための固有の業務ロジックであればActionでもいいと思います。

私の場合はテストもしたいのでPOJOに切り出しますが、
POJOの中では一切Servlet関連のAPIを使いません。
Servlet関連のAPIと切り離せるかがポイントじゃないでしょうか。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-01-28 11:43
ロジックの切り出しと安易に言っておられますが…

前提条件というのがあるのですよ。
大規模開発においては、開発を分業できるように、また、
保守をやりやすいように切り分けるようにするのですね。

でも、小規模においてはあんまり分離しすぎないほうがよかったりもします。

いろんな設計手法がありますが、メリット・デメリットを踏まえたうえで
自分の作っているプログラムにどう適用するかを考えることが重要です。
問答無用でこうすればよい、という万能解はありません。
1

スキルアップ／キャリアアップ（JOB@IT）