読者です 読者をやめる 読者になる 読者になる

新人SEの学習記録

14年度入社SEの学習記録用に始めたブログです。気づけば社会人3年目に突入。

学習記録:Spring

[学習記録] Spring

内容:1章 SpringとWebアプリケーションの概要(続き)

アプリケーションアーキテクチャ
  • アプリケーションアーキテクチャとは
    • アプリケーション全体の構造、共有の方式のこと
    • 要はシステム内のアプリケーションが共通で利用できるUIやDBアクセスの仕組みなどを指す
  • Webアプリケーション開発の目標
    • 1)ユーザの要件(機能要求・非機能要求)を満たす
    • 2)開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさなどの開発者や運用者の目標を満たす
  • アプリケーションアーキテクチャの必要性
    • 上記の目標を満たすため、開発効率を上げる
      • 簡単に理解できる、テストにコンテナの用意や設定などが不要…
    • 変化しやすいユーザの要求に対応できる柔軟な設計
      • 要求の変更はリリース後にも発生する。システムは開発者が思っているよりも長く使われる

※本書での用語

  • コントローラ:画面遷移やボタンなどの動作制御、セッションの管理などを行う
  • サービス:特定業務や処理のまとまりを制御する。トランザクションの起点。一般的にはステートレス
  • ドメイン:サービスから起動される、顧客や注文といったクラスの集まり
  • 凹型レイヤ
    • 外部の変更を受けやすい部分(GUI/Webサービス、永続化や他システム)を外側に
    • プレゼンテーション層とデータアクセス層が上部の左右にあり、ビジネスロジック層が下部にあるモデル
    • 外部の変更はプレゼン/データアクセス層が吸収し、ビジネスロジック層は影響を受けないことが重要
プレゼンテーション層の役割
  • 主な役割
    • UIの提供
    • コントローラの提供
  • コントローラ
    • いわゆるMVC2モデルのC
    • 適切なビジネスロジックを呼び出し、その結果をUIに返す
    • 状態をセッションに格納し利用するデータの管理を行う
ビジネスロジック層の役割
  • 業務処理のまとまりであるサービスと、業務で使用する顧客などのクラスの集まりであるドメインから構成
    • Webアプリケーションの機能追加や変更は、主にビジネスロジック層のロジックの変更
    • 柔軟なアーキテクチャを持ったWebアプリケーションを作るにはこの部分が最も重要
    • 特に、他の層はフレームワークを使用できるが、ビジネス層は毎回スクラッチになる上、顧客が最も処理内容について詳しい部分である
トランザクション管理
データアクセス層の役割
  • データアクセス層の設計指針
    • Connectionプーリングを利用:利用するたびにConnectionを生成・解放するのは効率が悪い
    • RDBが変わっても実装に影響がないように:設定ファイルで指定するだけに
    • RDBに依存したSQL文を記述しない:直接SQL文を記述するDBアクセスフレームワークでは注意。現在日時や連番主キー生成など
  • ビジネス層とデータアクセス層の分離
    • インタフェースからConnectionを分離する必要がある
    • 本書ではのちほどSpringを利用して実現
部品化
  • 部品化の促進で何が変わるのか?
    • 開発効率:部品毎に違うメーカに製造・テストを依頼できる
    • 柔軟性:パソコンのマウスやディスプレイのように容易に交換できる
  • 部品化にはインタフェースが大事
    • 電気製品でわかるとおり、部品間はコンセントやジャックなどなんらかのインタフェースで接続
    • アプリケーションも同じようにインタフェースでつながるよう部品化したい
  • インタフェース(穴の開いてる方)はどちらの部品が持つべきか?
    • 「偉い方」、API側やビジネスロジック層側
    • 何でもかんでもインタフェースで繋ぐべき、という訳ではない
  • どの程度まで部品化すればよいか?
    • ディスプレイ一体型があるように、ものによる。「必要に応じて」
Webアプリケーションが抱える問題
  • Springを利用しない場合に(つまり、Springで解決できる)Webアプリケーションが抱える問題について
  • ヘビーウェイトなコンテナ
    • 最近はEJBもDIxAOPコンテナになり、Springの優位性としては無くなっている
    • 現在はSpringのコンテナもやや重め
  • オブジェクトのライフサイクル
    • コントローラから呼ばれるサービスロジックのオブジェクトを毎回インスタンス
    • ユーザ数が増えたときにパフォーマンス低下やメモリを圧迫
    • Singletonにする回避策があるが、実装を変更する必要や、長生きしてもらっては困るオブジェクトのライフサイクルの作り込みも大変
  • 部品化
    • オブジェクト間の依存関係を疎結合に保つことで、拡張や変更を容易にし高品質に
    • オブジェクト同士がインタフェースのみに依存するように
    • フレームワークを使用しない場合、単にインタフェースを利用するだけでなく、FactoryMethodなどを導入する必要がある
  • これらの問題は、Springで解決できる
    • DIコンテナ:オブジェクトのライフサイクルの問題、部品化の問題を解決
    • AOP:技術隠蔽の問題を解決
Springの概要