⇧ 三年寝太郎に憧れますな...
ソフトウェアにおけるレイヤー
Wikipediaさんによりますと、
In software engineering, multitier 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.
Common layers
In a logical multilayer architecture for an information system with an object-oriented design, the following four are the most common:
- Presentation layer (a.k.a. UI layer, view layer, presentation tier in multitier architecture)
- Application layer (a.k.a. service layer or GRASP Controller Layer)
- Business layer (a.k.a. business logic layer (BLL), domain logic layer)
- Data access layer (a.k.a. persistence layer, logging, networking, and other services which are required to support a particular business layer)
⇧ 役割を分けるためにレイヤーを分けましょうってことらしいです。
Webシステム全体としては、
⇧ 3層で構成されるのが主流ということですかね。
で、サーバーサイド側に焦点を当てると、
⇧ 細かくレイヤーが分かれるようですと。
フロントエンドでも細かくレイヤーは分かれると思うけど、今回はサーバーサイドの話になります。
requestで渡ってきたFormの値の詰め替えはどのレイヤーですれば良いのか
前提として、画面などのフロントエンドからのrequestで渡ってきたFormの値をサーバーサイドで詰め替える話になります。
Spring Frameworkとか使ってると、
- @Controller
- @Service
- @Entity
- @Repository
のようなアノテーションが用意されているので、レイヤー分けを意識してるフレームワークなんだとは思われる。
Springのプロジェクトの中で、Spring Rooというものがあるらしいのですが、
⇧ レイヤー分かれてますね。
ただ、何故か、最近のSpringのドキュメントでは、レイヤー分けしたような概要図が存在してないっぽいので、
⇧ ネット上の情報を参考にしてみると、おそらく、Formは、上図で言うとDTOsに含まれるのかなと。
で、entityが上図で言うとDomain Modelになるので、Formの値をentityに詰め替えるような場合、Serviceレイヤーで行うということになるかと。
と思ったら、
⇧ 上記のような話もあり、結局のところ、Formの値の詰め替えってControllerで実施するのがメジャーなのかね？
ケースバイケースということで、
みたいな感じになるのかな？
結論が出ないので、開発してるシステムに合わせる感じになるのかな...
2023年3月1日（水）追記：↓ ここから
おそらく、ControllerクラスでForm→DTOへの詰め替えをして、ServiceクラスにはDTOを渡す感じにした方が良さそうな気がする。ControllerクラスをFatにしたくない場合は、Helperクラスとか作って処理を委譲する感じになるんかな？
2023年3月1日（水）追記：↑ ここまで
う～む、Spring Frameworkの公式の見解を是非聞いてみたいものですな。
関係あるか分からんのだけど、
GRASPとは、General Responsibility Assignment Software PatternあるいはPrinciple（汎用的責任性割り当てパターン/原則）の頭字語であり、オブジェクト指向設計に向けた九つの原則セットまたはパターンセットである。
「ソフトウェア開発において決定的な設計ツールになるのは、設計の原則の中で磨き上げられたメンタルであって、UMLやその他のテクノロジーではない」がラーマンの主張であり、GRASPとはオブジェクト指向開発を助けるためのメンタルツール（mental tool）であると定義している。
⇧ の説明の中で、「コントローラ -Controller-」は、
コントローラは、他のオブジェクトに必要な作業の実施を委譲する。他のオブジェクトの活動を制御し、連携させる。一般的なレイヤ構造を持ったオブジェクト指向のシステムでは、GRASP コントローラはアプリケーションやサービス層の一部と考えられる (アプリケーション層/サービス層、ドメイン層を明確に区別している場合）。
⇧ 他のクラスに作業を委譲しても良いとあるんだけども、どんな作業を委譲すれば良いかが結局分からんというね...
2023年3月7日（火）追記：↓ ここから
調べてたら、
⇧ フロントエンドとサーバーサイドを疎結合にするという意味では、面倒であっても、
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→DTO、DTO→Entityへの変換用のクラスを作るのが良いようです。
変換用のクラスを呼び出す場所は、
って感じになるんかな？
面倒くさく感じるかもしれないですが、DTOクラスを作りましょうってことですかね...
2023年3月7日（火）追記：↑ ここまで
毎度モヤモヤ感が半端ない...
今回はこのへんで。
