Skip to content

Latest commit

 

History

History
114 lines (94 loc) · 7.46 KB

1st.md

File metadata and controls

114 lines (94 loc) · 7.46 KB
Raw

PofEAAReading

Chapter1 レイヤ化

ソフトウェアアプリケーション開発におけるレイヤ化の歴史

  1. 初期のバッチ
  2. クライアント/サーバ
    • VB, Powerbuilder, Delphi によるUI(+SQL)/RDBMS
    • 課題:バリデーション、ビジネスルールの置き場
    • 失敗:UIに組み込む、ストアドプロシージャに組み込む -> どちらも重複しやすい
  3. オブジェクト指向
    • UIプレゼンテーションレイヤ、ドメインレイヤ、データソースレイヤの3レイヤによって解決したが、がシンプルだったため流行しなかった
  4. Webの登場
    • クライアントにビジネスロジックが入っているものはWebに置き換えにくいが、3層レイヤの場合はプレゼンテーションレイヤを作り替えるだけで済むようになった。

補足：レイヤは論理的区別、ティアは物理的区別とする。

3層レイヤそれぞれの概要

  1. プレゼンテーションレイヤ
    • ユーザーとソフトウェアの相互作用、対話を扱う。CUI,GUI,APIなど。
  2. ドメインレイヤ
    • 作業中のドメインに対してアプリケーションが行う作業を扱う。バリデーション、計算など。
  3. データソースレイヤ
    • 外部とデータやメッセージをやり取りしたりトランザクションの管理などを扱う。データベースや外部サービスなど。

この書籍では非対称なレイヤの構成について語る。（対称性のあるアーキテクチャとしては「ヘキサゴナルアーキテクチャ」がある。

レイヤの実行場所

ドメインロジックはクライアントでもサーバーでも実行できる。

Chapter2 ドメインロジックの構築

3つのパターン

  1. トランザクションスクリプト

    • 全ての処理を一括で行うような手続き的なモデル。
    • プレゼンテーションからの入力を受け取り、妥当性確認と計算を行い、データベースへ格納し、他のシステムへの操作を呼びだす。

  2. ドメインモデル

    • ドメイン内の名詞をはじめとするものを体系化したモデル。
    • 妥当性確認や計算はそれぞれ適切なオブジェクトに配置される。

  3. テーブルモジュール

    • テーブルを中心にドメインロジックを構築するモデル。
    • 継承やオブジェクト指向パターンを使用できないのがドメインモデルと異なる。

選択のポイント

図2.4を参照

サービスレイヤの導入による分割

  • ドメインレイヤを「サービスレイヤ」と「ドメインモデル、テーブルモジュール」の2レイヤに分割し、前者は後者の上に構築する。
  • 著者としては出来る限り薄くするのが良いと考えている。必要になるまでは追加しない。

Chapter3

共通的に言える事はそれぞれのパターンを局所的に混在させる事は可能であるし、完全な統一を目指すべきとはしないが、複雑性向上とのトレードオフになる。

アーキテクチャ

  1. テーブルデータゲートウェイ
    • テーブルデータゲートウェイはレコードセットを返すパターン。
    • テーブルモジュールパターンと相性が良い。
    • テーブルの各行をあるクラスのインスタンスとするのが行データゲートウェイ
  2. アクティブレコード
    • ドメインオブジェクトがデータベースを知っている。
    • 簡素なドメインモデルと相性が良い。
  3. データマッパー
    • ドメインオブジェクトとデータソースを分離するレイヤ的な役割。
    • 複雑なドメインモデルと相性が良い。

補足：書籍当時ではオブジェクト指向DBを使用していなかったが、2012年現在ではまた違うのではないだろうか。 また、日本でもアクティブレコードの扱いについてはブログでもあげられることがある。

振る舞いに関するテクニック

  1. ユニットオブワーク
    • コネクションやトランザクションを扱うオブジェクトであり、読み込み、書き込みのオブジェクトの変更点などを反映する。
  2. 一意マッピング
    • DBから読み込んだオブジェクトを一意にし、多重書き込み、多重読み込みを防ぐ。
    • パフォーマンス改善よりも一意性を保つ事が狙い。
  3. レイジーロード
    • オブジェクトのグラフで実際にDBから読み込むタイミングを実際に必要になるまで行わないようにオブジェクトを生成する方法。

リレーショナルな構造

RDBのリレーショナルをOOでどのように表現するか。

  • 一意マッピングでオブジェクトを一意に特定する。
  • 外部キーマッピングでDBのリレーショナルを表現する。実際には外部参照のIDがオブジェクトの参照になる。
  • 多対多の関係をRDBでは表現できないので、マッピング用のテーブルを作成することになる。
  • XMLなどを格納して使うシリアライズLOBのような手法も存在する。

補足：今ではKVSが増えて来たけど、RDBでXMLなKVSをやろうとすると最後のシリアライズLOBになりそう。

継承の構造

クラスの継承構造をRDBとどのように紐づけるか。

  1. シングルテーブル継承
    • 階層構造になっているクラスをまとめて1つのテーブルで保持する。他のクラスの情報を持つようになるため無駄な列が増えるが、変更には強い。
  2. 具象テーブル継承
    • 階層にある具象クラス毎に1つのテーブルで保持する。スーパークラスの変更によわい。
  3. クラステーブル継承
    • クラス毎に1つのテーブルで保持する。継承階層の下にあるオブジェクトをロードするために複数のJOINが必要なので遅くなりがち。

Chapter4

MVCの導入理由

  • プレゼンテーションレイヤとモデルを完全に分離することが目的であり、他のプレゼンテーションの追加を容易にさせる。
  • コントローラには2種類あり、入力コントローラとアプリケーションコントローラがある。
  • 入力コントローラはビューとやりとりをするコントローラで、アプリケーションコントローラはモデル側に内包されるプレゼンテーションとやりとりをするコントローラになる。

ビューパターン

  1. トランスフォームビュー
    • ページの構造に動的なロジックを書き込む手法。例としては、ASP, JSP, PHP。
  2. テンプレートビュー
    • 定型的にデータを変換する手法。例としてはXSLT。
  3. ツーステップビュー
    • 論理的なビューを作成してから、最終的に共通のビューを通してビューを作成する手法。

コントローラパターン

  1. ページコントローラ
    • ビューと入力コントローラを併せ持つ形になることが多いが、ビューに存在する1つのアクション毎にページコントローラとして捉える。
  2. フロントコントローラ
    • 1つのオブジェクトで全てのリクエストを処理する。