自閉症のonPHP：概要

こんにちは、habralyudi。



OnPHPは、ご想像のとおり、PHPで書かれたフレームワークです。 同様のツールと同様に、独自の長所と短所があり、私の意見では、より多くのツールがあります。



奇妙なことに、ハブでは、このフレームワーク専用のトピックは1つも見つかりませんでした。 どうやらその理由は、フレームワークにドキュメンテーションが完全に欠けているため、「フレームワーク自体」および「独自の」フレームワークに似ているためです。 ただし、これは完全に真実ではありませんが、後で詳しく説明します。







この記事の目的は、このフレームワークに関する既存の知識とその使用経験を結合するだけでなく、本当に価値のある開発に専門家コミュニティの注意を引くことです。 おそらく将来的には、収集された資料から、少なくとも何らかのドキュメントを編集することが可能になるので、共有する情報に感謝します。



私はフレームワークの作成者ではないことに注意してください。しかし、私はそのユーザーであり、それについてさらに学びたいと思っています。 それでは始めましょう。

はじめに

このフレームワークは、2005年以来、私が理解しているように、それを作成し、独自のニーズに合わせて開発した人々のチームで生まれ、成長しました。 公開されている最も古いバージョンは、2005年9月3日付のバージョン0.2です。 それ以来、フレームワークは大きく変化し、新しい機能が追加され、バグが修正されました。 現在、onPHPは、あらゆる規模のWebプロジェクトの基盤にふさわしい候補です。 最新の安定バージョンは1.0です。

長所と短所。

先ほど言ったように、どのツール（というよりも単純に）にはそれぞれ長所と短所があり、onPHPも例外ではありません。 利点の中で、私は以下を区別することができました。

1.迅速なアプリケーション開発。

OnPHPツールを使用すると、必要なクラスとそれらの関係をすばやく作成し、データベース構造を構築して依存関係を確認できます。 これはすべて、プロジェクトの本質を記述するXML形式のスキーマを使用して行われます。 詳細については、以下をご覧ください。 さらに、データにアクセスするための便利なツールがあります：Criteria（Hibernateからのよく考えられたポート）とOSQL。

2.水平方向のスケーラビリティ。

キャッシングの問題は深く解決されています。 私が理解しているように、これはフレームワークの誇りです。 さまざまな方法で非常にスマートにキャッシュできます（ファイルシステム、memcachedなど）。 さらに、データベース層は複数の接続での作業をサポートし、各創傷エンティティは使用する接続を指定できます。 実際にデータを異なるデータベースに透過的に保存します。

3.柔軟性。

それは、ほとんどの場合、フレームワークがプロジェクトに機能を作成するための特定のアクションテンプレートを課さないという事実にあります。 同時に、フレームワークは、必要なものを作成するために必要なすべての機能を提供します。 フレームワークのアーキテクチャは、多くの有名なデザインパターンを使用し、フレームワーク自体は、独自のクラス（StaticFactory、Singleton）を「隠す」機能を提供します。

4.スピード。

私が理解しているように、それは主に非常に柔軟なキャッシングによって達成されます。 しかし、別の要因があります-キットに付属しているphp用のモジュール。 常に必要とされるクラスの一部はモジュールとして設計されており、間違いなく作業を加速しました。

5.品質と信頼性。

コードは単体テストでカバーされています。 フレームワークに表示される各新機能は、テストでカバーされています。 使用の経験から、構築されたシステムの動作の安定性と予測可能性に喜んで驚きました。

6.高品質でクリーンで明確なコード。

おそらくこれは主観的なものですが、これは私の意見であり、明らかにクリエイターもそうです。 すぐに慣れる厳格なコーディングsleleは、コードの素早い認識に貢献し、コード内のコードを見るたびに生じる特定の美的喜びさえももたらします。



おそらくすべてのメリット。 欠点 ：

1.ドキュメントの欠如。

フレームワークの作成者は、APIが最高のドキュメントであると信じています。 個人的には、私はそれらに同意しないので、議論とその後のメモの間に、少なくとも何らかのドキュメントが生まれることを期待して、このメモを書くことにしました。

2.小​​さなコミュニティ。

この欠点は最初の結果です。なぜなら、ドキュメントが不足しているためにエントリのしきい値が大幅に増加し、多くの人が消えたがっているためです。 質問や提案の議論は、主にメーリングリストを通じて行われます。メーリングリストでは、月に1、2回議論が行われます。

3.クラスの競合。

フレームワークのクラスにはプレフィックスがないため、プロジェクトをこのフレームワークに移行するときに問題が発生します。 そのため、onPHPで名前が使用されているクラスに対して他の名前を作成する必要がある場合があります。

どこから始めますか？

git masterブランチには、プロジェクトの典型的な構造、エントリポイント（index.php）、データベースの使用、フォームの使用（入力データを受信および検証するための強力なツール）および不完全なメモに関する推奨事項がある非常に短いチュートリアルがありますまだインキュベーターにあるACL。

インキュベーター。

これはonPHPの一部であり、最終的なフォームをまだ正式に取得していないフレームワークの部分があり、変更、機能の破損、その他の不安が生じる可能性があります。 開発、デバッグ、テストは次のとおりです。 フレームワークの新しい部分はインキュベーターで開発され、安定化された後、メインセクションになります。

そのため、現時点のインキュベーターには、Acl、Tsearch（PostgreSQLの全文検索）、FormRendering（フォームの集中表示-Formオブジェクトとそのプリミティブ）、Application（アプリケーションと便利な構成のための設定の組み合わせ）、さらにいくつかのパッケージがあります。

メタ。

メタフォルダーにあるフレームワークのこの部分は、エンティティとそのプロパティを記述し、将来のアプリケーションに必要なクラスを作成する機会を提供します。 スキームはXML形式で実行され、添付のmeta.dtdを使用して検証できます。



回路例：

  <？xml version = "1.0"？>
 <！DOCTYPEメタ構成システム "meta.dtd">
 <メタ構成>
 <クラス>
         <クラス名= "著者"テーブル= "著者">
                 <プロパティ>
                         <識別子/>
                         <プロパティ名= "名前"タイプ= "文字列"サイズ= "50"必要= "true" />
                 </ properties>
                 <パターン名= "StraightMapping" />
         </ class>
         <クラス名= "Book"テーブル= "books">
                 <プロパティ>
                         <識別子/>
                         <プロパティ名= "タイトル"タイプ= "文字列"サイズ= "50"必須= "true" />
                         <プロパティ名= "著者"タイプ= "著者"リレーション= "OneToOne"必須= "true"フェッチ= "lazy" />
                 </ properties>
                 <パターン名= "StraightMapping" />
         </ class>
 </ classes>
 </メタ構成> 

ここで面白いのは：



-エンティティごとに、所有するプロパティとそのタイプが示されます。 これに基づいて、メタビルダーはデータベーススキーマにどのような変更を加える必要があるかを推奨し、これを使用してフォーム内のこれらのオブジェクトを検証することもできます。



-エンティティ間の関係をすぐに示すことができ、生成されたクラスに反映されます。 OneToOne、OneToMany、ManyToManyを使用できます。 そのため、私は常にOneToOne接続を使用していましたが、他の種類の接続について知りたいと思います（理論ではなく、これは大丈夫、つまりonPHPの実装です）。



-パターン-は、将来のクラスのパターンです。 残念ながら、すべてのテンプレートの機能はわかりませんが、その一部を次に示します。

1. StraightMapping-名前から、これがデータベーステーブルの1つのレコードへのオブジェクトの直接マッピングであることは明らかです。 これはActiveRecord M. Fowlerに他なりません。
2. EnumerationClassは列挙です。 データベースにテーブルはないが、線形リスト（id => name）であるクラス。 変更されない、またはほとんど変更されないデータに使用されます（たとえば、月、星座など）
3. AbstractClass-抽象クラス。 他のクラスが同じスキームで継承されるスキームの抽象クラスを定義するために使用されます。

残りのパターン（ DictionaryClass、SpookedClass、SpookedEnumeration、ValueObject、およびInternalClass ）はまだ不明であり、知っている人が教えてくれることを望み、書き留めておきます。



-fetch =“ lazy”-これは、オブジェクトをアセンブルするときに、Authorプロパティをアクセスする前にロードする必要がないことを示しています。 上記の例で、IDでBookオブジェクトをアンロードすると：

$book = Book::dao()->getById(1);

$author = $book->getAuthor();

次に、Authorオブジェクトを構築するために、データベースで要求が行われ、パラメーターの値が取得されます。 fetch = "cascade"を使用すると、すべてのリンクのすべてのデータが1つの要求でデータベースから削除され、その後、関連するオブジェクトが収集され、追加の要求なしで使用できます。



これですべてのメタができるわけではありませんが、簡単に概要を説明できます。 クラスの生成を始めましょう。

コード生成。

メタフォルダーにはbin / build.phpスクリプトがあり、近くにあるクラスを使用して、回路をクラスに変換します。 使い方を見てみましょう：

Usage: build.php [options] [project-configuration-file.inc.php] [metaconfiguration.xml]

メタはありますが、構成ファイルはあります-いいえ。 作成しましょう。



ルートには、構成ファイルのテンプレートであるglobal.inc.php.tplファイルがあります。 次のようにコピーして変更します。

a）定数PATH_CLASSESを追加します-生成されたクラスがある場所。

b）set_include_path（）に追加します：

.PATH_CLASSES.PATH_SEPARATOR

.PATH_CLASSES.'Auto'.PATH_SEPARATOR

.PATH_CLASSES.'Auto'.DIRECTORY_SEPARATOR.'Business'.PATH_SEPARATOR

.PATH_CLASSES.'Auto'.DIRECTORY_SEPARATOR.'DAOs'.PATH_SEPARATOR

.PATH_CLASSES.'Auto'.DIRECTORY_SEPARATOR.'Proto'.PATH_SEPARATOR

.PATH_CLASSES.'Business'.PATH_SEPARATOR

.PATH_CLASSES.'DAOs'.PATH_SEPARATOR

.PATH_CLASSES.'Proto'.PATH_SEPARATOR

c）データベース接続パラメーターを追加します。

DBPool::me()->setDefault(

DB::spawn('PgSQL', 'user', 'password', 'localhost', 'dbname')

->setEncoding('utf-8')

);

次に、 build.phpを実行します 。

  $ ./meta/bin/build.php ./global.inc.php ./schema/project.xml 

 onPHP-1.1：MetaConfigurationビルダー。

既知の内部クラス：Range、DateRange、TimestampRange、IdentifiableObject、IdentifiableTree、NamedObject、NamedTree、それだけです。

クラスを構築する：
	著者：
		 AutoProtoAuthor（クラス/自動/プロト/ AutoProtoAuthor.class.php）
		 ProtoAuthor（クラス/ Proto / ProtoAuthor.class.php）
		 AutoAuthor（クラス/自動/ビジネス/ AutoAuthor.class.php）
		著者（クラス/ビジネス/ Author.class.php）
		 AutoAuthorDAO（クラス/自動/ DAO / AutoAuthorDAO.class.php）
		 AuthorDAO（クラス/ DAO / AuthorDAO.class.php）

	本：
		 AutoProtoBook（クラス/自動/プロト/ AutoProtoBook.class.php）
		 ProtoBook（クラス/ Proto / ProtoBook.class.php）
		 AutoBook（クラス/自動/ビジネス/ AutoBook.class.php）
		ブック（クラス/ビジネス/ Book.class.php）
		 AutoBookDAO（クラス/自動/ DAO / AutoBookDAO.class.php）
		 BookDAO（クラス/ DAO / BookDAO.class.php）

コンテナの構築： 

 DBスキーマの構築：
		 schema.php（クラス/自動/ schema.php）

推奨されるDBスキーマの変更： 
テーブル 'authors'が見つかりません。スキップします。
テーブル「本」が見つかりません、スキップします。

古いファイルの確認： 

すべての既知のクラスをコンパイルしようとしました...完了しました。

生成されたファイルの健全性の確認： 

	著者（2/1 /
エラー：42P01：リレーション "authors"は存在しません-SELECT "authors"。 "Id"、 "authors"。 "Name" FROM "authors" WHERE（ "authors"。 "Id" IS NOT NULL）ORDER BY "authors" 。 "id" LIMIT 1

 [例外トレースの切り抜き] 

何が起こったのか：ビルダーは構成ファイルを取得し、スキーム（クラスの構築セクション）に従ってクラスを作成し、スキーマファイル（DBスキーマ構築セクション）を作成し、古いファイルをチェックし、すべてのプロジェクトファイルの構文をチェックし、生成されたクラスの正確性をチェックして、まだテーブルを作成していません。 修正します。 ベースに移動して、2つのリクエストを実行します。

CREATE TABLE authors (id serial PRIMARY KEY);

CREATE TABLE books (id serial PRIMARY KEY);

build.phpを再度実行します。

  $ ./meta/bin/build.php ./global.inc.php ./schema/project.xml 

 onPHP-1.1：MetaConfigurationビルダー。

既知の内部クラス：Range、DateRange、TimestampRange、IdentifiableObject、IdentifiableTree、NamedObject、NamedTree、それだけです。

クラスを構築する：
	著者：
		 AutoProtoAuthor 
		 AutoAuthor 
		 AutoAuthorDAO 

	本：
		 AutoProtoBook 
		オートブック 
		 AutoBookDAO 

コンテナの構築： 

 DBスキーマの構築：
		 schema.php 

推奨されるDBスキーマの変更： 
 ALTER TABLE "authors" ALTER COLUMN "id" TYPE BIGINT;
 ALTER TABLE "authors" ADD COLUMN "name" CHARACTER VARYING（50）NOT NULL;

 ALTER TABLE "books" ALTER COLUMN "id" TYPE BIGINT;
 ALTER TABLE "books" ADD COLUMN "title" CHARACTER VARYING（50）NOT NULL;
 ALTER TABLE "books" ADD COLUMN "author_id" BIGINT NOT NULL REFERENCES "authors"（ "id"）ON DELETE RESTRICT ON UPDATE CASCADE;
 CREATE INDEX "author_id_idx" ON "books"（ "author_id"）;


古いファイルの確認： 

すべての既知のクラスをコンパイルしようとしました...完了しました。

生成されたファイルの健全性の確認： 

	著者（2/1 / F / C / H / T）、本（3/1 /
エラー：42703：列books.titleは存在しません-SELECT "books"。 "Id"、 "books"。 "Title"、 "books"。 "Author_id" FROM "books" WHERE（ "books"。 "Id" IS NOT NULL）ORDER BY "books"。 "Id" LIMIT 1 

推奨されるDBスキーマの変更に注意して、これらのクエリを実行し、 build.phpを再度実行します。

  $ ./meta/bin/build.php ./global.inc.php ./schema/project.xml 

 onPHP-1.1：MetaConfigurationビルダー。

既知の内部クラス：Range、DateRange、TimestampRange、IdentifiableObject、IdentifiableTree、NamedObject、NamedTree、それだけです。

クラスを構築する：
	著者：
		 AutoProtoAuthor 
		 AutoAuthor 
		 AutoAuthorDAO 

	本：
		 AutoProtoBook 
		オートブック 
		 AutoBookDAO 

コンテナの構築： 

 DBスキーマの構築：
		 schema.php 

推奨されるDBスキーマの変更： 

古いファイルの確認： 

すべての既知のクラスをコンパイルしようとしました...完了しました。

生成されたファイルの健全性の確認： 

	著者（2/1 / F / C / H / T）、ブック（3/1 / F / C / H / T）、完了。 

すべてのクラスが生成されます。 それらを見てみましょう。 PATH_CLASSES定数で指定されたディレクトリには、4つのサブディレクトリが含まれるようになりました。

• Auto ：build.phpが実行されるたびに再生成される変更不可能なクラスを含むクラス。
• ビジネス ：必要なロジックを補う、変更できるビジネスオブジェクトと変更するビジネスオブジェクト。
• DAO ：データアクセスオブジェクト、頻繁に使用するサンプルを配置できるデータアクセスオブジェクト。
• Proto ：オブジェクトのプロトタイプとそのプロパティを記述するクラス。

作成されたクラスの使用例。

コード：

require "global.inc.php";



DBPool::me()->getLink()->begin();



$author = Author::create()

->setName('Martin Fowler');

Author::dao()->add($author);



$book = Book::create()

->setTitle('Patterns of Enterprise Application Architecture')

->setAuthor($author);

Book::dao()->add($book);



DBPool::me()->getLink()->commit();

結果：

  dbname => select * from authors;
  id | お名前      
 ---- + ---------------
   1 | マーティン・ファウラー
 （1行）

 dbname => select * from books;
  id | タイトル|  author_id 
 ---- + --------------------------------------------- ---- + -----------
   1 | エンタープライズアプリケーションアーキテクチャのパターン|  1
 （1行） 

次回はonPHPのMVCと本格的なサンプルアプリケーションについて書き、質問される内容を強調する予定です。 PHPに関するトピックが、この記事に対するコメントの形で前向きで建設的な応答を見つけることを願っています。

ご清聴ありがとうございました。



UPD ：

参照：

-onphp.org

-GIT

-onPHPの作成者の1人であるDenis Gabaidulinのブログ