Pine Frameworkの基本仕様

Pine FrameworkのアーキテクチャはMVC2デザインパターンを採用していますが、MVC2の定義だけでは解決できなかった数々の問題について更に掘り下げを行い、より高度で洗練されたデザインパターンを形成しています。

以下が、一般的なMVC2デザインパターンの概念図です。

MVC2デザインパターン

MVC2デザインパターンを採用したフレームワークの多くが共通して抱えている問題の1つが、ファットコントローラーと呼ばれる問題です。MVC2デザインパターンではControllerが処理の中核を成すためにここにプログラムコードが集中しやすい構造となっています。このため、システム更改の度にコントローラーにコードが追記されてファイルが肥大化していき、しばしばメンテナンス不能な状態にまで膨れ上がってしまう問題がありました。

Pine Frameworkが採用したアプローチ

この問題を解決するため、Pine Frameworkでは、PHPのWEBフレームワークとして有名な『Symfony』での実装を参考にActionというもう一つの新しいアーキテクチャを採用しました。

Controllerが担保していたWEBリクエスト毎の処理をそれぞれ独立したActionに委譲する事で、Controllerを雑多な役割から開放し肥大化を防いでいます。

Pine Frameworkのアーキテクチャ

また、ViewにおいてはTemplateエンジンを介在させることでHTML内から可能な限り表示に関するプログラム処理を排除しています。これは、ページデザインからプログラムロジックを排除し、エンジニアではないデザイナーが最初から最後まで常にシステムのフロント側に携わり続ける事を可能にします。

TemplateエンジンはSymfonyプロジェクトの製品である「Twig」を採用しています。Twigは実績のある高度なTemplateエンジンであり、デザインとプログラムコードの分離を行うのに大きな役割を担ってくれます。

洗練された便利なフレームワーク

Pine Frameworkには他にも洗練された様々なアーキテクチャが備わっており、開発の容易さ、高速開発性能、メンテナンス性能、安全性、柔軟性、利便性など、どれをとっても他に類を見ない程高度で先進的なフレームワークとなっています。特筆すべきは、独自で奇抜な実装はほとんど採用せず極めて一般的な概念・技術のみを利用して構築しているため、学習コストは他のフレームワークに比べて遥かに低くなっています。

例えば、近年有名になってきているPHPフレームワーク『Laravel』ではテンプレートエンジンに『Brade』という独自ライブラリを採用していますが、このライブラリが『Twig』に勝る点はあまり見当たりません。ですからPine Frameworkでは万人の学習コストを考慮し広く用いられているテンプレートエンジンである『Twig』を採用しています。

Pine Frameworkでは車輪の再発明を行わず、既存のライブラリよりも便利になる場合のみにおいて独自のアーキテクチャを採用するように開発を行っています。

また、Pine Frameworkの多くのアーキテクチャは設定値駆動(パラメタドリブン)であり、単純な値適宜変更するだけで自動的に意図する動作を行わせることが出来ます。これは学習コストを低下させて開発速度を上げる以上に、複数の処理が適切に同じ動作をする事を保証し、ソフトウェア品質の向上を容易にさせる事に寄与します。

ここで紹介した内容はPine Frameworkを構成する内容のほんの一部です。次項から紹介するPine Frameworkのアーキテクチャの詳細をご覧いただければ、Pine Frameworkがあなたの組織のシステム開発にとって強力な基盤となることをご確認いただけることでしょう。

あなたの組織があらゆるシステム開発の問題から開放され、本質的なビジネスの問題のみに焦点を絞って検討を行い活動が出来るようになる事を祈念します。

Pine Frameworkのアーキテクチャ

Pine FrameworkはMVC2デザインパターンを基にしていますが、更に掘り下げを行ってより洗練されたデザインパターンを形成しています。

Pine Frameworkのアーキテクチャ

デザインパターンの詳細

Pine Frameworkを構成する基本要素について、順番に説明します。

1. Router

Routerは、ユーザから受け取ったWEBリクエストを妥当なControllerに渡します。Routerは担当となるControllerに情報を渡すだけであり、認証や入力のヴァリデーション、リダイレクトといった処理は一切行いません。

リクエストで要求されているコマンドActionの判定はここで行われます。

コマンドとは一般的なWEBアプリケーションでいうところの『画面』に相当する物で、例えば『ユーザー管理画面』や『注文管理画面』はそれぞれ、『ユーザー管理コマンド』『注文管理コマンド』と言い換える事ができます。Controllerはこのコマンド毎に1つ生成されます。

この『ユーザー管理コマンド』には通常『新規ユーザー登録』『ユーザー情報変更』『ユーザー削除』といった複数の処理が含まれますが、これらがActionとなります。

Router

2. Controller

Controller

Routerから渡された情報を確認し、その情報に適切なDTO(後述)とActionを選別して処理をActionに委譲します。バリデーションなどは行いませんが、通信種別(HTTPかHTTPSか)やアクセスの可否(アカウント認証済み判定)のような、アプリケーションの本質よりも低いレイヤーでの判断についてはControllerが行います。

Actionに処理を委譲した後でActionから処理が戻されると、Controllerは適切なViewを選別して処理をViewに委譲します。

3. DTO(Data Transfer Object)

DTO

1つのWEBリクエスト内で共通して利用されるデータコンテナです。ControllerがDTOインスタンスを生成します。生成されたDTOインスタンスはその後、Action、UME(後述)、Model、View、その他必要なあらゆる場所に渡され、その過程で生成されるあらゆる情報の格納・提供を行います。

DTOはPine Frameworkにおいてとても重要な役割を果たしており、Pine Frameworkでアプリケーションの構築を行う上で、システムコードが複雑になるのを防いでいる最大の陰の立役者であり、シンプルでありながら最も重要なアーキテクチャです。

4. Action

Action

1つのWEBリクエストにおけるビジネスロジックの進行管理を担当します。実際のビジネスロジックは細分化されてModelが担当しますが、Actionはそれらの実行順序や実行結果の成否毎の処理の分岐など、マネジメント・統括の役目を果たします。

また、Actionはビジネスロジックの実行に先立ってUMEの管理も行い、ユーザからのリクエストの妥当性判断も行います。

ActionはWEBアプリケーションに於いての花形 の存在です。

Actionは設定値駆動型であり、アプリケーションの品質を保つための多くの処理は設定値によって自動で動作します。

極めて重要な点として、永続化データ層に対するトランザクション処理もActionが行います。この動作も設定値駆動です。

5.UME(User-request Manipulate Engine)

UME

1つのWEBリクエストにおけるユーザからのリクエストについて、その妥当性検査を担当します。

単純な妥当性検査(ヴァリデーション)にとどまらず、設定に沿ったデータの補正や、後処理のためのデータ整形なども行います。

UMEは設定値駆動型であり、ヴァリデーション処理は設定値によって自動で行われます。

6.Model

ビジネスロジックの実体です。通常、永続化データ層(データベース等)のCRUD処理(参照・変更)はここで行われます。このため、Modelではメンバ変数としてBamboo(後述)への参照がデフォルトで提供されています。

Modelは永続化データ層へのアクセサ(Bambooへの参照)が提供されていますが、必ずしもそれを行わなければならないわけではありません。

Model

7.Bamboo

Bamboo

データベースアクセスのためのORM(Object Relational Mapping)ライブラリです。アーキテクチャとしてDataMapperパターンを採用しているため、Ruby on Railsをはじめとして一般的に利用されている抽象化パターンであるActive RecordやDAOのように、ORMオブジェクト自体が1つのTableに結びついてはいません

Bambooは各テーブルとそのエンティティであるDataModelを結びつけマッピングします。

このため、特筆すべき情報として、テーブルの結合が容易に行えます

ORMの概念比較

ORMの概念比較

BambooはPHPのデータベースアクセスに対する抽象化レイヤである「PDO」のラッパーです。このため、Bambooの仕様はPDOの仕様に準拠します。

BambooはPHPにおけるシングルトン・デザインパターンを採用しています。このため、1つのWEBリクエスト内での1つの永続化データ層に対する接続は常に1つで共有されており、Pine Framework内のどこから呼び出しても同じ接続インスタンスが利用されます。これは、複数の永続化層スキーマに対する接続は、その数だけ適切に準備される事を意味します。

INSERTやUPDATE、DELETEといったDMLは、テーブルの抽象モデル(Entity)であるDataModel(後述)を利用して簡単に行なえます。

また、SELECTの結果のマッピングは、DataModelに対して、あるいはPHPの汎用オブジェクトである\stdClassに対しても行えます。このため、テーブルの結合(JOIN)にあたって予めDataModelを準備する事も、\stdClassにマッピングすることも自由に行なえます。

どちらを利用するかは実装者の判断に委ねられ、そこに何らかの制限事項は一切ありません。

8.DataModel

DataModel

DataModelは永続化データ層であるデータベースのテーブルのEntity(実像)オブジェクトです。データベースにおける1つのTableまたはView、および任意のSELECT結果が1つのDataModelに紐付いており、Bambooを介して行われるCRUDの要求・結果は、通常、DataModelオブジェクトを利用して行われます。

DataModelのプロパティは静的型であり、データベースから取得されたデータはマッピングされるDataModelの各プロパティに設定されている型に自動でキャストされます。DataModelのプロパティがサポートする型はstring、integer、double、datetime、date、boolそしてlobです。これらは、PHPおよびPHPが標準で提供するPDO、そして一般的なデータベースのカラム型について総合的に判断して決定されています。

9.View

View

ViewはWebBrowser上の描画に関する情報の出力を行います。ビジネスロジックとは関係の無い、表示上の分岐やループ処理についてはViewが担当しますが、これらの処理は実際にはTemplate(後述)に委ねられます。

Viewは描画を行うTemplateの選定と描画を行うデータの準備、Templateに渡す変数の定義、最終的なTemplateの描画実行などを行います。

特筆すべき点として、Pine FrameworkにおけるViewは他の多くのフレームワークのように永続化データ層に対する参照を制限しません。このため、Viewではメンバ変数としてBambooへの参照がデフォルトで提供されています。

本来のMVC2デザインパターンにおいてもこれは制限されておらず、Viewが直接永続化層のデータを参照できることは、ModelとViewをより一層疎結合にする事に寄与します。

10.Template

Template

WEBにおけるユーザインターフェイスであるHTMLの記述場所がTemplateです。

Templeteは効率的なアプリケーション開発の為に最低限必要な分岐処理とループ処理、フィルタやファンクションのようなロジック呼び出しといった例外を除き、HTMLのみで構成されます。これは、非エンジニアであるデザイナーが常にアプリケーションに関わり続ける事を可能にします。

11.Utility

Utility

Utilityは、Pine Framework内の任意の場所で利用できる、用途が完全に独立したツールです。

UtilityはPine Frameworkのライフサイクルには組み込まれておらず、必要に応じてどこからでも自由に利用できます。

Utilityは通常static(静的)なクラスとして提供され、ステートレス(状態を持たない)であり、利用に一切の制限がありません。

上記のように、Utilityはステートレスであってその利用に条件を一切必要としません。これは、Utilityがあらゆる場面で利用可能な資産となりうる事を示唆します。

アプリケーションとしての本質であるビジネスロジックはModelに記述されるべきですが、ビジネスモデルそのものの実体はUtilityに記述されるべきです。

一例を挙げましょう。ECサイトに於いて、1つの商品の注文画面からの顧客の注文を処理するコードはビジネスロジックであるのでModelに記述されるべきですが、注文内容に合った金額を算出するためのプログラムはUtilityとして提供されるべきです。なぜなら注文自体はそれが行われた状況毎に処理が変わりますが(例えば特定のキャンペーン画面からの注文は商品代金に対して5%引き等)、金額の算定方法は一定の基準を設けて行われるものであり、それはビジネスの筋道(ロジック)ではなく実体であるからです。

Modelが1つのリクエストに紐づくのに対し、Utilityは結合を一切持たないためにどこからでも呼び出しができます。つまり、Utilityとして提供された金額算定プログラムは、注文方法が変わろうともあらゆるリクエストで普遍的に利用できる事を意味します。これが「資産となりうる」という事の意味です。