人気ブログランキング | 話題のタグを見る

BEAR.Saturdayの紹介


こんにちは。Woman技術の三浦です。

私は新入社員でして、最近まで研修として社内ツールを作っていたのですが、
今回はその開発で使用した、PHPのフレームワークの1つであるBEARについて
紹介したいと思います。

ちなみに作成した社内ツールは、すごく簡単に言ってしまえばQiitaの簡易版です。
みんな使ってくれないかなー(チラッ


まあそれはともかく。


みなさんは、BEARはご存知でしょうか?
エキサイトでは、標準的に使われているPHPフレームワークです。

BEARには、BEAR.Friday、BEAR.Saturday、BEAR.Sundayが存在します。

日曜日に近づくほど新しい物になっていくのですが、古くから継続しているサービスが
Saturdayを使っていることもあって、私が社内ツール作成で利用したのはSaturday
ですので、そちらについて紹介します。


BEAR.Saturdayとは?

BEAR.Saturdayの紹介_f0364156_09004461.jpeg
ではまず、BEAR.Saturdayの良い所や大変な点は…と行きたいところなのですが、
BEARを全く触ったことがない人にとっては、いきなりそういう点を言っても
わかりにくいかと思います。

そこで最初に、BEAR.Saturdayの簡単な説明からしていきます。
もし良い所・大変な点から見たい、という方がいましたら、下の方にスクロールして頂けると。

さて、BEAR.Saturdayの公式Githubの概要をみてみると、このように書いてあります。

BEARはリソース指向のPHP Webアプリケーションフレームワークです。
ページ - リソースリクエストとリソース状態のビューへのプッシュ
リソース - インターフェイスとURIを持った情報
ビュー - リソースの表現

正直、私がBEARに全く触れずにこの部分を見た時、よくわかりませんでした。

そこで、図にしてみました。

BEAR.Saturday概要

BEAR.Saturdayの紹介_f0364156_09280864.png

図内の番号通りに順を追って説明していきます。


ページ

まず1、URLを叩くと、ページに移ります。

ここで、GET・POSTパラメータがあった場合は、ページで参照できます。


ページでは、Webページに出力したいデータに関する処理を行います。

ただ、場合によってはDBなどのデータを参照したりする必要もあるでしょう。

その場合は、2、リソースへアクセスします。

リソース

リソースは、DBなどの外部のデータとのやり取りのインタフェースとしての役割を持ちます。

ページから要求されて、DBの値を参照するのはもちろん、DBにレコードを追加したり、
削除したりする場合も、リソースを通して行うことになります。


無事、GET・POSTパラメータやリソースからもらったDBの情報を元にしてデータを
処理できたら、3、ビューへと移ります。

ビュー

ビューでは、ページで処理したデータを受け取り、それをWebページとして出力可能な
状態とします。


そして、Webページが見られる状態になる、というわけです。


ここまでは大丈夫でしょうか?では、もう少し詳しく見ていきます。


BEAR.Saturday少し詳細

BEAR.Saturdayの紹介_f0364156_09294803.png

ページ1

ページとは、Page.phpを親クラスとしたPHPファイルです。

基本的には、この中に、onInject()メソッド、onInit()メソッド、onOutput()メソッドが用意されています。


1でURLが叩かれると、まずページの中のonInject()メソッドが呼ばれます。

もしGET・POSTパラメータがあった場合は、onInject()メソッドで処理をすることで、
ページ内でパラメータの値が使用できるようになります。


onInject()での処理が終わると、onInit()メソッドの処理が始まります。

データの処理は基本的にここで行われることになります。

また、リソースへのアクセス、2、も、このメソッド内で行われます。


では一旦、リソースの解説に移ります。

リソース

リソースは、Ro.phpクラスを親クラスとしたPHPファイルとなっています。

リソースクラスでは、DBに対してどんな事をしたいかによって、使用する関数が異なります。


readしたい場合はonRead()を。

insertしたい場合はonCreate()を。

updateしたい場合はonUpdate()を。

そして、deleteしたい場合はonDelete()を、それぞれ使うことになります。

ページ2

さて、ページに戻りましょう。

onInit()メソッド内で十分に処理が行われ、終了すると、次はonOutput()メソッドに移ります。


onOutput()メソッドでは、処理したデータをビューに渡す処理、3、を行います。

正確には、ビューとはsmartyというテンプレートエンジンのtplファイルによって構成されている
のですが、どのtplファイルを使用するかを指定する、という部分です。

ビュー

ビューとは、一度書きましたが、smartyと呼ばれるテンプレートエンジンのtplファイルによって
構成されています。

共通処理部分を担当するlayoutsディレクトリ配下のtplファイル、

各Webページの固有の処理となるpagesディレクトリ配下のtplファイル、

そして使い回すことを目的としたelementsディレクトリ配下のtplファイルという、
三種類のtplファイルを利用することとなります。


最後にそこでWebページとして表示可能な状態にして、全処理が終了する、という
形になります。


いかがだったでしょうか?


BEARには他にも、「newを使わずfactory()やdependency()などを使う」、「リソース
でのonLink()」、「キャッシュ」など、ここでは紹介しなかった様々な機能が存在しますが、
そこまではここでは説明せず、あくまで入門部分を書いておくことにします。

そういったことは、こちらのマニュアルを見ていただいたり、自分で使ってみて慣れていく
のが良いかと思います。


では続いて、私が実際にBEAR.Saturdayを使った時に感じた良かった点と大変だった点を
述べていきます。


BEAR.Saturdayの良かった点・大変だった点

ここから述べていくのは、あくまで私が感じたことです。

特に私は今までPHPフレームワークというものを触ったことがなく、あまり比較が取れない
と思いますが、そこはご了承ください。


良かった点

さて、まずは良かった点を述べていきます。


1. 機能ごとにファイルやクラスが分離されている

先ほど説明したとおり、BEAR.Saturdayでは、処理がページ、リソース、ビューで
分かれています。

これによって、2つの利点が考えられます。


1つ目は、コードの可読性の向上です。

データの処理、外部からのデータの読み書き、Webページの表示が同じファイルに書かれて
しまっていると、どうしてもコードがごちゃごちゃして、コードを書いているときは
もちろんのこと、後々他の人が見た時や自分が見た時に大変な思いをすることに
なってしまうというのは簡単に想像できると思います。

コードが処理ごとに分かれていること、更にそれが、onInject()やonInit()、onOutput()
などにも分かれていることで、コードの可読性が向上します。


2つ目は、共同開発です。

例えばページとビューがわかれていることで、エンジニアとデザイナーが、コンフリクトを
あまり起こさずに同時に開発を進めていくことができます。

一つのファイルに処理系と表示系が混在していたら、コンフリクトの嵐になってしまうこと
は想像に難くありません。


2. クラスの命名規則

PHPでコードを書く際、クラス名には「こうした方が良い」という命名規則があります。

ただそれは、あくまで「こうした方が良い」というものであり、そうしなくてもPHPは
動作します。

もしクラス名がその時々、その人々によって全く異なるものとなっていたら、後でそれを
見た時に、 理解するのに多大な時間が時間が掛かってしまう可能性があります。


そこでBEAR.Saturdayでは、クラスの名前の付け方が決められていて、それ以外の名前を
つけるとエラーとなるようになっています。

例えばファイルのパスがRo/Sample/Example.phpであれば、クラス名は
Ro_Sample_Exampleとなります。


3. リソースの取得方法の統一

これは、知った時に結構感動した部分です。

通常、例えばDBからデータを取得するときとテキストファイルからデータを取得するときは、
処理が異なります。

DBであれば、DBのホストやDB名を解決し、sql文などを入れ込む処理が必要です。

一方テキストファイルの読み込みなら、そのテキストファイルまでのパス、ファイル内の
文字列を読み込む処理などが必要になります。


なのですが、BEARだと非常に簡単になります。

ページにて必要な処理は、以下のようになります。

例えば、Ro/DataBase.phpというDBに接続するためのファイルがあった場合、
DB内容をreadするなら、

$this->_resource->read(['uri' => 'Ro/Database'])->getBody();

という処理です。

次に、Ro/Text.ymlという設定ファイルを読み込みたいときは、

$this->_resource->read(['uri' => 'Ro/Text'])->getBody();

という処理になります。


見てみると分かる通り、内容的には全く違う処理が必要でも、ページからのアクセス方法は
全く同じになるのです。

もちろんDBであれば、readする際にWHEREの条件などのパラメータを渡す必要があるのですが、それも
配列で渡すだけで、ほとんど処理は変わりません。


BEARでは、こういった外部のデータそれぞれを同じ処理で取得できるようになっています。

これによって、ページでの処理が綺麗にリソースでの処理と分けることができるのです。


さて、ここまではBEARの良い所を書いてきましたが、BEARをやっていく上で大変だった
点もあります。


大変だった点

覚えることが多い

ビューの部分で、BEARはsmartyを使っている、と説明しました。

smartyはPHPのためのテンプレートエンジンで、PHPとhtmlを簡単に同時に利用できるようにするものです。

とても便利ではあるのですが、smarty独特のコードの書き方となり、色々と覚える必要が
あります。

また、Webページからデータを送信する際のフォームでは、html quick-formというものを
使っています。

こちらはPHPで作成・呼び出しをすることができ、かつ設定次第では、二重送信や
クロスサイトリクエストフォージェリという脆弱性をなくしてくれるという利点がある
のですが、こちらもsmartyと同じく、使い方を学ぶ必要があります。

このように、BEAR.Saturdayは様々な便利なテンプレートエンジンなどを取り入れて、
綺麗にコードを書けるようになっている一方で、色々とBEAR以外のことを学ぶ必要がある
のが、少し大変でした。


以上が、私がBEAR.Saturdayを使ってみて感じたことになります。

使ってみたい、と思ってくださった方はいるでしょうか?


この内容が、これからBEARを使っていこうとする方、あるいは復習として見ている方の
手助けに、少しでもなれば幸いです。


それでは、よいBEARライフを!



エンジニア募集

エキサイトでは、エンジニアとして一緒に働いてくださる方を、新卒採用と中途採用で
募集しています。

ご興味のある方は、こちらの採用情報ページをご覧ください!


by ex-engineer | 2016-09-20 11:00