実用的なアプリケーション開発 4 ビジネスロジック(設計)

フォーム値の検証が完了したら、いよいよロジック部分(アプリケーションの本質的な仕事をする部分)を記述します。

注意点としては、アクションクラス(perform()メソッド)にはアプリケーションの核となる処理をベタベタと記述してはいけません。

基本的にはほぼ全ての処理はアプリケーションの核となるクラス(モデルクラスやマネジャークラス)に記述し、アクションクラスはそれらを単純に呼び出すのみ、というイメージです。

例えば

app/action/Login/Do.php:

public function perform()
{
    // メールアドレスをキーにしてユーザオブジェクトを生成
    $user = new User($this->backend, $this->af->get('mailaddress'));
    // 認証処理
    $result = $user->auth($this->af->get('password');
    // 以降結果によってビューを変更、等...
}

のようにするか、またはManagerを使って

public function perform()
{
    $um = $this->backend->getManager('user');

    // 認証処理
    $result = $um->auth($this->af->get('mailaddress'), $this->af->get('password'));
    // 以降結果によってビューを変更、等...
}

というようにするのがよいでしょう。

なぜこのような設計するのかというと、一言でいうと「カプセル化」「疎結合」を 実現するためです。

もうちょっと具体的なメリットとしては、

• ビジネスロジックの再利用性が高まる
  • 各アクション/ビュークラス間でのコードの重複を防ぐ
  • スマホアプリ用APIとWebページでロジックを共有できる
• 単体テストが書きやすくなる
• 将来システムが大きくなったときに、別のサブシステム(=microservice)として切り出しやすくなる

などがあります。

実際にあった例として私の経験談をお話します。

あるとき、Ethnam上で動していたMongoDBの集計処理を、マイクロサービス化して別サーバに分離したことがあります。その際、フレームワークをEthnamからSilexに変更したのですが、コアのロジックをモデルクラスに書いていたおかげで、モデルクラスはそのまま再利用できました。

繰り返しになりますが、perform()メソッドを記述する際の注意をまとめると、

• アクションクラスにアプリケーションの核となる処理を記述しない
• アクションクラスはどんなに長くても100〜200行程度におさめる
• 他のアクションクラスやビュークラスと重複する処理を記述しない
• 重複する処理がある場合は、traitやモデルやマネージャに処理をまとめる

となります。