Actionの実装デザイン

LastaFluteからの提案です。

• いきなりまとめ
  • 実装デザインの提案
  • Logic についてはこちら
  • Bean についてはこちら
• Actionの役割
  • バウンダリ、かつ、ファサード
  • もし、ActionでTransactionがなければ
  • 規約ベースなので Action は自然分離
• Actionに何を実装するか？
  • フローコントロール (ファサード)
  • 再利用しない検索や更新など (ちょこっとロジック)
  • つまりこんな感じです
  • 検索の再利用は部品単位で
• ActionをアシストするAssist
  • WEB依存でちょこっとまとめたい
  • Assistクラスのパッケージ
  • AssistクラスはWEBに依存してOK
  • Assistクラスは画面に依存してOK!?
  • Assistクラスも普通にDIできる
  • WEBに依存したロジックを作らないためにも
  • チグハグなスーパークラスを作らないためにも
  • Jobには、JobAssistが
• No more, ごちゃごちゃスーパークラス
• No more, あっちらこっちら参照
• No more, しっちゃかめっちゃかクラス名
  • クラス名の規約は？
  • クラス名の慣習は？

いきなりまとめ

実装デザインの提案

本気でDDDをやるフェーズまで達していない段階、かつ、プロジェクトで独自にアーキテクチャを定義していない場合の、LastaFlute からのデフォルト実装デザインの提案です。

Action (バウンダリ、かつ、ファサード: Transactionあり)

フローコントロール、そして、再利用しない検索や更新など(ちょこっとロジック)を書く

WEB依存 "する" 処理の再利用や、ちょこっと役割分担は、(Action)Assist

WEB依存 "しない" 処理の再利用は、(Business)Logic

Logic (ビジネスロジック)

WEB依存しない再利用するものを書く (二箇所以上で呼ばれて初めて Logic に)

ただし、検索の再利用はできるだけ ArrangeQuery にて (Logicでのまるごと再利用は限定的に)

Logicの名前は、"モノ+Logic" はダメ、できるだけ "モノ+業務+Logic"

Logic についてはこちら

Logicは、また別途まとめています。

Bean についてはこちら

入れ物クラスの Bean (Form や JsonResult など) についてもまとめています。

Actionの役割

バウンダリ、かつ、ファサード

Action には、すでにTransactionがかかっています。 単なるバウンダリ(境界)としての役割だけでなく、ビジネスロジックのファサード(玄関) としての役割を持つことができます。

厳密なアーキテクチャではその役割を分離することが多いですが、LastaFlute ではシンプルさを追求するために、一つにしています。 スタートアップの開発では、その二つを分離することのメリットを享受する前に変更がたくさん入り、逆に分離によるデメリットの方が足かせになりやすいと考えます。

Actionに何を実装するか？

フローコントロール (ファサード)

先ほど出てきた "A やって B やって C やって" という、そのリクエストにおけるTransactionに含む必要のある流れの呼び出しを司ります。

仮に、C で例外が発生しても、A と B がしっかりとロールバックされるように。

再利用しない検索や更新など (ちょこっとロジック)

ActionでDBアクセスしてはいけないというポリシーは LastaFlute には存在しません。その画面でしか使わない ConditionBean による検索や更新など、Action で入れてもOKです。

つまりこんな感じです

シンプルな処理ですが...

e.g. SeaLandAction in harbor @Java
/**
 * @author yourname
 */
public class SeaLandAction extends HarborBaseAction {

    // ===================================================================================
    //                                                                           Attribute
    //                                                                           =========
    @Resource
    private PurchaseBhv purchaseBhv;

    // ===================================================================================
    //                                                                             Execute
    //                                                                             =======
    @Execute
    public HtmlResponse index(int productId, SeaLandForm form) {
        validate(form, messages -> {}, () -> {
            return asHtml(path_Sea_SeaLandHtml);
        });
        ListResultBean<Purchase> purchaseList = selectPurchaseList(form);
        List<SeaLandRowBean> beans = mappingToBeans(purchaseList);
        return asHtml(path_Sea_SeaLandHtml).renderWith(data -> {
            data.register("beans", beans);
        });
    }

    // ===================================================================================
    //                                                                              Select
    //                                                                              ======
    private ListResultBean<Purchase> selectPurchaseList(SeaLandForm form) {
        return purchaseBhv.selectList(cb -> {
            cb.setupSelect_Member();
            cb.setupSelect_Product();
            cb.query().setProductId_Equal(productId);
            cb.orScopeQuery(orCB -> {
                orCB.query().setMemberId_Equal(userId);
                orCB.query().queryMember().existsMemberFollowingByYourMemberId(followingCB -> {
                    followingCB.query().setMyMemberId_Equal(userId);
                });
            });
            cb.query().existsPurchasePayment(paymentCB -> {
                paymentCB.query().setPaymentMethodCode_Equal_AsPaymentMethod(form.pay);
            });
            cb.query().addOrderBy_PurchaseDatetime_Desc();
        });
    }

    // ===================================================================================
    //                                                                             Mapping
    //                                                                             =======
    private List<SeaLandRowBean> mappingToBeans(ListResultBean<Purchase> purchaseList) {
        return purchaseList.mappingList(purchase -> {
            SeaLandRowBean bean = new SeaLandRowBean();
            bean.purchaseId = purchase.getPurchaseId();
            purchase.getMember().alwaysPresent(member -> {
                bean.memberName = member.getMemberName();
            });
            purchase.getProduct().alwaysPresent(product -> {
                bean.productName = product.getProductName();
                bean.productHandleCode = product.getProductHandleCode();
            });
            bean.purchaseDate = toStringDate(purchase.getPurchaseDatetime()).get();
            bean.purchasePrice = purchase.getPurchasePrice();
            return bean;
        });
    }
}

検索の再利用は部品単位で

もし、検索の中で再利用したいものがあれば、ArrangeQuery を使いましょう。これは、DBFluteのポリシーでもあります。検索の丸ごと再利用は多くの場合失敗に終わります。

e.g. 特別過ぎる優待会員を検索 @Java
MemberCB cb = new MemberCB();
cb.query().arrangeTooPreferentialMember(); 
cb.query().addOrderBy_...();
... = memberBhv.selectList(cb);

e.g. ある特別な商品を購入したことのある会員名称が "S" で始まる正式会員という条件を設定するメソッド @Java
public class MemberCQ extends BsMemberCQ {

    ...

    /**
     * 特別過ぎる優待会員
     */
    public void arrangeTooPreferentialMember() {
        setMemberName_PrefixSearch("S");
        setMemberStatusCode_Equal_Formalized();
        existsPurchaseList(purCB -> {
            purCB.query().setProductId_Equal(SPECIAL_PRODUCT_ID);
        });
    }
}

ActionをアシストするAssist

WEB依存でちょこっとまとめたい

Assistクラスは、単なるActionのアシストです。

e.g. Assist class @Java
public class SeaAssist {

    ...
}

WEBや画面に依存してるので、(Logicではなく) Action の中で記述するべきものだけど、ちょこっとまとまったクラスにしたい というときに使います。

• Actionの中のprivateメソッドがでかくなってきたので、ちょっと外に出したい
• WEB依存した処理を、A画面とB画面でちょっと再利用したい

そういうときに作ります。

Assistクラスのパッケージ

再利用しないなら、その Assist を使う Action クラスの隣でいいかと思います。

e.g. package of no-recycled assit class @Directory
app
 |-web
 |  |-sea
 |  |  |-SeaAction.java // uses SeaAssist
 |  |  |-SeaAssist.java
 |  |  |-SeaForm.java

再利用するのであれば web.base パッケージに、任意のパッケージを作って再利用すると良いでしょう。

e.g. package of recycled assit class @Directory
app
 |-web
 |  |-base
 |  |  |-maihama
 |  |  |  |-ResortAssist.java
 |  |-sea
 |  |  |-SeaAction.java // uses ResortAssist
 |  |  |-SeaForm.java
 |  |-land
 |  |  |-LandAction.java // uses ResortAssist
 |  |  |-LandForm.java

AssistクラスはWEBに依存してOK

RequestManager や SessionManager や CookieManager などガッツリ使ってOKです。 どちらかというと、そういったWEBに絡んだ処理を再利用するためのものと言えるでしょう。

ただ、あまり ActionResponse の処理を Assist に入れると、Action で何をやっているのかわかりづらくなるので、そこはあくまで Action の役割と捉えて、そのための手続き的な処理を Assist でやるのが良いでしょう。

Assistクラスは画面に依存してOK!?

画面に依存していいいかどうかは、再利用するのかどうか次第です。

再利用しない Assist であれば、べったり呼び出し元の Action に依存させてOKです。 つまり、FormクラスやBodyクラスも参照しちゃってOKです。パッケージ的にも不自然ではありません。 この場合の Assist の役割は、単に Action で書くのがちょっと量が多いので外に出すという感じですね。

再利用する Assist であれば、もちろんとある固定の画面に依存することはできませんが、 例えば Form や Body 自体を再利用しているとかであれば(その場合、Form や Body も base パッケージに)、 その Form や Body を Assist から参照しても良いでしょう。

Assistクラスも普通にDIできる

Actionクラスの中で、普通に DI できます。

また Assistクラスの中で、様々なコンポーネントをDIすることもできます。

WEBに依存したロジックを作らないためにも

どうしても、WEBに依存したまとまった処理を再利用したいと考えることがあります。

一方で、Action はバウンダリ、かつ、ファサード、Logicには再利用するものだけを記述する、という方式を追求すると、 それなりに Action には処理が入り込む可能性があります。

そうしたとき、ちょっと気軽にWEB依存したままのクラスを作ってしまえばいいなと、Assistがないアーキテクチャで開発していたときに思っていました。 でも、アーキテクチャにそういう概念がないと、なかなか誰も新しいクラスを作ろうとはしません。 そのしわ寄せが Logic に行くのです。

チグハグなスーパークラスを作らないためにも

というか、これはチグハグなスーパークラスにさせないためのものでもあります。 LogicをWEB依存させないようにすると、しわ寄せがスーパークラスに来ます。

先の通り、スーパークラスは概念を形づけるためのものです。 ある程度の便利にするためのメソッドが入り込むのは仕方ないとしても、特定の業務的なものは入れるものところではありません。

それなら、ActionAssist を使って、再利用しましょう。

Jobには、JobAssistが

Actionではなく、LastaJob の Job クラスでも、同じように Assist クラスが利用できます。考え方としては基本的に同じです。

e.g. No way, many business methods in super class @Java
public abstract class MaihamaBaseAction extends ... {

    // ★どかどか業務メソッドが追加されていく。。。
}

e.g. stileto reference @Directory
app
 |-web
 |  |-sea
 |  |  |-SeaAction.java
 |  |  |-SeaForm.java
 |  |-land
 |  |  |-LandAction.java // uses SeaForm

e.g. use base for recycle @Directory
app
 |-web
 |  |-base
 |  |  |-sea // rename if better name exists
 |  |  |  |-SeaForm
 |  |  |-MaihamaBaseAction
 |  |  |-...
 |  |-sea
 |  |  |-SeaAction // uses base.sea.SeaForm
 |  |-land
 |  |  |-LandAction // uses base.sea.SeaForm
 |  |-piari
 |  |  |-dstore
 |  |  |  |-PiariDstoreAction // uses PiariForm
 |  |  |-PiariDetailAction // uses PiariForm
 |  |  |-PiariEditAction // uses PiariForm
 |  |  |-PiariForm // cane be recycled in same package