※当サイトの記事には、広告・プロモーションが含まれます。

requestで渡ってきたFormの値の詰め替えはどのレイヤーですれば良いのか

nazology.net

三年寝太郎に憧れますな...

ソフトウェアにおけるレイヤー

Wikipediaさんによりますと、

In software engineeringmultitier architecture (often referred to as n-tier architecture) is a client–server architecture in which presentation, application processing and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.

https://en.wikipedia.org/wiki/Multitier_architecture

Common layers

In a logical multilayer architecture for an information system with an object-oriented design, the following four are the most common:

https://en.wikipedia.org/wiki/Multitier_architecture

⇧ 役割を分けるためにレイヤーを分けましょうってことらしいです。

Webシステム全体としては、

www.ibm.com

⇧ 3層で構成されるのが主流ということですかね。

で、サーバーサイド側に焦点を当てると、

docs.oracle.com

⇧ 細かくレイヤーが分かれるようですと。

フロントエンドでも細かくレイヤーは分かれると思うけど、今回はサーバーサイドの話になります。

requestで渡ってきたFormの値の詰め替えはどのレイヤーですれば良いのか

前提として、画面などのフロントエンドからのrequestで渡ってきたFormの値をサーバーサイドで詰め替える話になります。

Spring Frameworkとか使ってると、

  • @Controller
  • @Service
  • @Entity
  • @Repository

のようなアノテーションが用意されているので、レイヤー分けを意識してるフレームワークなんだとは思われる。

Springのプロジェクトの中で、Spring Rooというものがあるらしいのですが、

docs.spring.io

⇧ レイヤー分かれてますね。

ただ、何故か、最近のSpringのドキュメントでは、レイヤー分けしたような概要図が存在してないっぽいので、

www.petrikainulainen.net

⇧ ネット上の情報を参考にしてみると、おそらく、Formは、上図で言うとDTOsに含まれるのかなと。

で、entityが上図で言うとDomain Modelになるので、Formの値をentityに詰め替えるような場合、Serviceレイヤーで行うということになるかと。

と思ったら、

stackoverflow.com

teratail.com

⇧ 上記のような話もあり、結局のところ、Formの値の詰め替えってControllerで実施するのがメジャーなのかね?

ケースバイケースということで、

  • Form→DTO
    Controllerで値を詰め替え
  • Form→Entity、DTO→Entity
    Serviceで値を詰め替え

みたいな感じになるのかな?

結論が出ないので、開発してるシステムに合わせる感じになるのかな...

2023年3月1日(水)追記:↓ ここから

おそらく、ControllerクラスでForm→DTOへの詰め替えをして、ServiceクラスにはDTOを渡す感じにした方が良さそうな気がする。ControllerクラスをFatにしたくない場合は、Helperクラスとか作って処理を委譲する感じになるんかな?

2023年3月1日(水)追記:↑ ここまで

う~む、Spring Frameworkの公式の見解を是非聞いてみたいものですな。

関係あるか分からんのだけど、

GRASPとは、General Responsibility Assignment Software PatternあるいはPrinciple(汎用的責任性割り当てパターン/原則)の頭字語であり、オブジェクト指向設計に向けた九つの原則セットまたはパターンセットである。

GRASP - Wikipedia

計算機科学者クレーグ・ラーマン英語版の1997年著作「実践UMLパターン -Applying UML and Patterns-」で初めて紹介されている

GRASP - Wikipedia

「ソフトウェア開発において決定的な設計ツールになるのは、設計の原則の中で磨き上げられたメンタルであって、UMLやその他のテクノロジーではない」がラーマンの主張であり、GRASPとはオブジェクト指向開発を助けるためのメンタルツール(mental tool)であると定義している

GRASP - Wikipedia

⇧ の説明の中で、「コントローラ -Controller-」は、

コントローラは、他のオブジェクトに必要な作業の実施を委譲する。他のオブジェクトの活動を制御し、連携させる。一般的なレイヤ構造を持ったオブジェクト指向のシステムでは、GRASP コントローラはアプリケーションやサービス層の一部と考えられる (アプリケーション層/サービス層、ドメイン層を明確に区別している場合)。

GRASP - Wikipedia

⇧ 他のクラスに作業を委譲しても良いとあるんだけども、どんな作業を委譲すれば良いかが結局分からんというね...

2023年3月7日(火)追記:↓ ここから

調べてたら、

stackoverflow.com

⇧ フロントエンドとサーバーサイドを疎結合にするという意味では、面倒であっても、

Form→DTO→Entity

という感じで、DTOの変換を挟むのが良いようです。

上図の例で言うと、UI BeanがFormに該当すると思われますが、

That's why you need to adapt your data between layers to work with objects that make sense to a particular layer. For example, you could add a BOAdapter (between UIView and Service) and DTOAdapter (between Service and DAO). Those adapters are usefull for transforming your data inside each POJO's format. For example, you could have in your BO(=UIBean) a date expressed inside three strings and you want a Date object for DTO so you transform it inside the BOAdapter:

https://stackoverflow.com/questions/34383760/architectural-layers-in-java-web-application

⇧ Form→DTODTO→Entityへの変換用のクラスを作るのが良いようです。

変換用のクラスを呼び出す場所は、

  • Form→DTODTO→Form
    Controllerで値を詰め替え
  • DTO→Entity、Entity→DTO
    Serviceで値を詰め替え

って感じになるんかな?

面倒くさく感じるかもしれないですが、DTOクラスを作りましょうってことですかね...

2023年3月7日(火)追記:↑ ここまで

毎度モヤモヤ感が半端ない...

今回はこのへんで。