一般社団法人 全国個人事業主支援協会

COLUMN コラム

WEBアプリを開発するとき、Formクラスをビジネス層のServiceクラス等に渡してはいませんか?
私は渡していました( ゚Д゚)

今回はこのことについて記載したいと思います。
なお、Formクラスと書いていますが、JSONをデシリアライズしたDTOも同様です。

なぜFormクラスをビジネス層に渡してはいけないのか

まず前提としてWebアプリの構成は以下の通りとします。

  • プレゼンテーション層:外部からのデータを受け取る
  • ビジネス層:業務固有の処理(ビジネスロジック)を行う
  • インフラストラクチャ層:DBアクセスを行う

外部からのデータをプレゼンテーション層で受け取り、それを下層のビジネス層に渡します。
ビジネス層では具体的なビジネスロジックに従って処理を行い、必要に応じてインフラストラクチャ層の処理を利用してDBアクセスを行います。
そして、その結果をプレゼンテーション層が外部に返すという流れですね。

外部からのデータをデータをプレゼンテーション層で受け取るわけですが、この時にデータを受け取るのが今回話題に上げているFormクラスです。
つまりFormクラスに外部から渡されたデータが全て格納されているわけです。

さて、ビジネス層はプレゼンテーション層が受け取ったデータをもらって処理を行うので、単純に考えるとFormクラスをビジネス層に渡せばいいのではないかと考えてしまいませんか?

これをしてはいけません。というのが今回の話題です。

では、なぜしてはいけないのか。
簡潔にお伝えすると、ビジネス層がプレゼンテーション層に束縛されてしまうからです。

プレゼンテーション層には多くのエンドポイントが存在しますが、それぞれ異なるFormクラスを利用するのが普通です。
ここで、ビジネス層がFormクラスを受け取るように実装されていると、特定のエンドポイントからの処理しか実行できなくなってしまいます。

例えば「hogehoge/user」というエンドポイントからは利用できるが、「hogehoge/manager」というエンドポイントからは利用できなくなってしまいます。

ビジネス層はどのようにして情報を受け取るべきか

では、ビジネス層はどのように情報を受け取るべきでしょうか。
よくあるのは、ビジネス層が利用するDTOを作成して、FormクラスからそのDTOにデータをコピーするという方法です。

プレゼンテーション層側で、ビジネス層が利用できる形にしてから渡してあげることで、ビジネス層はプレゼンテーション層の束縛から解放されます。

それっぽく言うと、ビジネス層がプレゼンテーション層に依存しなくなるということです。

一見、Formクラスと同じようなDTOを作成するのは無駄に思えるかもしれません。
しかし、Webアプリは作って終わりではありません。
世の中の変化に合わせて変化し続ける必要があります。

ビジネス層がプレゼンテーション層に依存していると、それだけ変化しづらくなります。
ビジネス層にDTOを作成するのは変化に強くするためには有効な方法の一つです。

The following two tabs change content below.

この記事をシェアする

  • Twitterでシェア
  • Facebookでシェア
  • LINEでシェア