フレームワーク構築入門研修の参加報告
はじめに
研修に参加してきたので、忘れないように自分用にoutputしておく。
カリキュラム内容
コース概要
JavaによるWebアプリケーションアーキテクチャを設計する際によく利用されるデザインパターンについて学習し、その実装方法について学習していきます。 講義で採り上げるパターンはシステム開発でよく利用されるMV*やIoC、サービスクラス、DAOなどです。本コースで学んだアーキテクチャに関する知識は既存のフレームワークを理解するのにも役立つ知識ですので、アーキテクチャ設計を一から行わない方にもお勧めのコースになっています。
学習目標
- レイヤ化されたWebアプリケーションの構成を理解する
- 学習した各パターンの意義と使いどころを理解する
- Webアプリケーションのアーキテクチャを構築する際の選択肢を持つ
学習内容
フレームワークとは
- Inversion of Control
プレゼンテーションレイヤに関するパターン
- MV*
ドメインレイヤに関するパターン
- サービスクラス
データソースレイヤに関するパターン
- DAOパターン
-
- 動的なクラスやメソッドの利用
- アノテーションの実装と利用
-
- 依存性の解決（ファクトリー、DI、AOPの実装）
- 汎用的なDAOの実装
1. 基本の考え方（デザインパターン）
デザインパターンとは、オブジェクト思考に基づいて経験則から得られた、プログラミングにおける優良なパターンのこと。 GoF本では23個が提示されている。
その中で、代表的な4つについて学習した。
①Template Methodパターン
目的：具体的な処理をサブクラスに任せる
スーパークラスでは処理の順番だけが決められ、サブクラスでは具体的な処理が実装されている。
※スーパークラスにテンプレートを記載する、という意味合いからメソッド名が付けられた。
②Factory Methodパターン
目的：インスタンス作成をサブクラスに任せる
抽象度を高めることで、可用性を高めることができる。 しかし、ファクトリを指定する手段を別途考えなくてはならない。 →DIで解決する。
③Singletonパターン
目的：たった１つのインスタンス
＜他の言語の例＞
scalaだと、
「object ○○」でシングルトンとして使用可能。
⇨自分たちで作成しようとしないこと
④Strategyパターン
Strategyとは処理内容（=戦略）の意味。
2. プレゼンテーションレイヤに関するパターン
MVC（Model-View-Controller）
MVCとは、ユーザインターフェースの動作を３つの明確な役割へ分割するアーキテクチャパターン。
- View・・・プレゼンテーションレイヤ（変わりやすい）
- Controller・・・プレゼンテーションレイヤ（変わりやすい）
- Model・・・ドメインレイヤ、データソースレイヤ（変わりにくい）
その他、MVP、MVVM、MVWなど多数あるが、どの機能をどこに実装するかは設計者によって様々である。 ただ１つ言えるのは、変わりやすいものと変わりにくいもので分けている、ということだ。 例）Angularでは、MVW（W:Whatever）を使用している。
<参考>
参考ではあるが、インタラクティブさや使いやすさ向上などのために、JSが多様化されたものが増えてきた。その例がGoogleマップである。
DOM操作を使用し、ページ全体ではなくその一部分を細く書き換えるような動作を行うものだ。これらの構造を作成するためのフレームワークとしてBackbone.jsやAngular.jsが挙げられる。
これらはサーバ上の動作処理と同じかそれ以上をクライアント側でも複雑な処理を記述する必要がある。
そのため、サーバ側でもクライアント側でもMVCモデルを使用することで。複雑さへの対応を取ることが求められつつある。
しかしそれだとクライアントもサーバもModelが配置され、冗長的なので、サーバ側もJSで作成しようという動きが出てきた。その中で出てきたのがサーバサイドJSとしてのnode.jsである。
※これについては後日調べてoutput
Front Controller
Front Controllerとは、すべてのリクエストを受け付けるコントローラを１つだけ用意するアーキテクチャパターン。
例えば、設計上の課題として共通の処理だけど本質的ではない部分（前処理や後処理）を各サーブレットに実装しなければならない場合に、これらの部分を個別にサーブレット内に実装するのは明らかに無駄が多い。このような共通処理を実装するにはどうすればよいかの解決策として、Front Controllerパターンがある。
その際、Front Controllerにはアクションクラスにリクエストを振り分ける何らかのルールを与える必要がある。その設定方法としては、設定ファイルを用意したり、ロジックとしてif-else文で作り込んだり、アノテーションによって記述したり、などの方法がある。
設定ファイルにリクエストとActionの関係が書かれていくとxmlが大きくなる「xml地獄」が起こる。そのため、xmlを小さくしようというのがトレンドである。
※設定ファイルのトレンドについては次の機会に調べてoutput
Template View
HTMLページに特殊なタグを埋め込むことで、動的な情報を表示するテンプレートとする。（要はJSPのこと）
問題点に対して純粋な（特殊なタグを全く入れない）HTMLをテンプレートとして使用するプロダクトも存在している。（例：Thymeleaf）
※これについては後日調べてoutput
3.ドメインレイヤに関するパターン
サービスレイヤ
プレゼンテーションレイヤとの境界に位置し、ドメインレイヤに対する処理を受け付ける役割。 導入を検討するのは、複数のDBテーブルを使ってのトランザクション処理が必要な場合など。
トランザクションスクリプト
実際にビジネスにおいて行われる手続きをそのままプログラムロジックとして記述するパターン
ドメインモデル
その業務（ドメイン）における処理内容と処理するデータを一体化させたモデル
トランザクションスクリプトとドメインモデルのどちらを使用するかは、システムの難易度によって変わる。JavaによるWebアプリケーションはトランザクションスクリプトを使うことが多い。
なぜトランザクションスクリプトが多く使われるのかというと、トランザクションスクリプトは昔ながらの手続き指向に近いからだ。そのため、DB内のデータも素直に処理することができる。またドメインモデルだと、ドメインモデルとDBテーブル間で、モデルの表現の違いを変換する何らかの仕組み（※１）が必要だからだ。
※１ OR Mapper(Object RDB)
ドメインモデルによるシステム開発は、ドメイン駆動設計がある。
顧客と対話しながら、業務領域（ドメイン）を表すモデルを中心としてシステムを構築していく考え方のことだ。
例）顧客が本当に欲しかったもの（風刺画）
DI(Dependency Injection)
オブジェクトの注入のこと。
近年多くの業務システムは多層的な構造になっており、コンポーネントが他のコンポーネントに数珠つなぎのように依存した構成になっている。
これではコンポーネント単独ではテストできないし、再利用性も低い。→品質向上と開発の効率化が行いにくい
もっと依存性を低くしようということより、生まれた。
AOP(Aspect Oriented Programming)
アスペクト指向プログラミング
重複・横断的な処理を画一的に外部から介入し処理を行う。（処理そのものを介入する。）
例）ログ出力、トランザクション制御、セキュリティ、例外ハンドリング
4. データソースレイヤに関するパターン
Data Access Object(DAO)
DBアクセスをビジネスロジックから切り離す
Data Transfer Objet(DTO)
データを保持し他レイヤに運搬することを目的とするオブジェクト
O/Rマッピング
メモリ内のオブジェクトとRDBテーブルを相互に変換する仕組み
例）OR Mapper(Object RDB)
- Hibernate・・・難易度高め。独自のHQLを使用。
- mybatis・・・簡易的。SQLを重視したい場合に人気。
- JPA（Java Persistence API）・・・背後にHibernateが実装してあり、使いやすくするためにIFを定めている
- Doma・・・Hibernateやmybatisのいいとこどり。seasarのサポートは切れているが、依存していないので使用可能。おすすめ。
※ Domaについては今後調査する
