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

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

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

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

例えば

app/action/Login/Do.php:

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

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

```php
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やモデルやマネージャに処理をまとめる

となります。