05．設計6： ビジネスロジックの設計

概要

ここでは、ビジネスロジックの設計についてみていきます。

ビジネスロジックの設計

Daoやビジネス層は、WEBと切り離した実装になるようにします。

よくやりがちな間違いとして、Daoやビジネス層を画面ごとに作っていくという設計をする人がいます。

画面ごとに作成してしまう良くない例

ユーザ情報変更画面専用のビジネスロジック、Daoを作ってしまう例です。

これでは、画面が増えるたびにメソッドかクラスを追加しないといけなくなります。

ControllerクラスはWEBのためのクラスなので、画面が増えた時にクラスが増えるのは当然ですが、

ビジネスロジック、Daoは業務のためのクラスですので違います。

ビジネスロジックやDaoは、WEBの処理とは無関係に業務として汎用的に作るべきです。

もちろん、ビジネスロジック、Daoが大きくなりすぎる場合は、クラスを分割することも検討します。

WEBに関わる情報を扱ってしまうNGな例

上記のルールに従えば分かるかと思いますが、BussinessやDaoでHTMLの情報に関わることもNGです。

【NGな例】

【Daoの例】

public List<Data> findData(){

String sql = "select case when code = '1' then 'red' "

+ "when code='2' then 'blue' "・・・

・・・・

return ret;

}

【JSPの例】

<td><span style="color:${data.color};">太郎さん</span></td>

WEBに表示すべき色の情報 "red" をSQLで取得しています。

これは大げさな例かもしれませんが、似たようなことをしている方はいらっしゃると思います。

このやり方だと、この画面でしか使用できなくなります。また、バッチ処理など他の用途にも使用できなくなります。

【JSPで対応するOKな例】

【Daoの例】

public List<Data> findData(){

String sql = "select code , name, ・・・ "・・・

・・・・

return ret;

}

【JSPの例】

<c:set var="color">

<c:choose>

<c:when test="${data.code == 1}">red</c:when>

<c:when test="${data.code == 2}">blue</c:when>

：

<c:otherwise>black</c:otherwise>

</c:choose>

</c:set>

<td><span style="color:${color};">太郎さん</span></td>

Daoが汎用的に使用できます。Daoを呼び出しているビジネスロジックも汎用的にできます。

また、画面ごとにビジネスロジックやDaoを作らなくてすむようになります。

他の方法としては、Controllerで対処しても良いです。

Controllerは、画面に関する処理を担当する層なので、ここで画面の処理を行うのは正当です。

【Controllerで対応するOKな例】

【Controllerの例】

public static class Form{

static private Map<Integer, String> colorDataMap = new HashMap<Integer, String>();

static{

colorDataMap.put(1, "red");

colorDataMap.put(2, "blue");

}

public String getColorDataMap(int key){

return colorDataMap.get(key);

}

【JSPの例】

<td><span style="color:${form.getColorDataMap(data.color)};">太郎さん</span></td>

mapを共通化しておけば、WEBアプリ上のさまざまな画面で使用することもできます。

補足

もう少し補足します。

開発するときは、2つのチームに分けることが多いと思います。

１つは、汎用的な基盤、ビジネス、Daoを作る担当。

もう１つは、画面デザイン、コントローラを作る担当。

このあたりも、会社によって違うと思います。

1つ目の担当者には高い経験値を持つ人に実施してもらい、難度の高い、全体を見渡した基盤、業務の設計をします。

つまり、開発の最初の方で少人数で汎用的でコアな部分を設計・実装します。

ある程度完成したら人数を増やして、難易度の低い、システマチックにコーディングできる部分を

実装していきます。

こうすると、稼働が少なくなると思います。

Created Date： 2015/03/28