典型的な開発者のキャリアについてのジョークがあります：
- フレームワークを使用しません
- フレームワークを検出します
- 彼は彼自身のフレームワークを書いています
- フレームワークを使用しません
もちろん、ポイント4は、Composer
を使用
して独自のフレームワークを構築し、さまざまなサードパーティコンポーネントから
フレームワークを作成する、新たに発見された機能を指します。
PHPエコシステムがさまざまなフレームワークの不足に悩まされていないことは誰もが知っているので、比較的最近作成された別のフレームワークを見たときは少し驚きました。
これは
Webinyと呼ばれ、必要と思われる改善や変更が一
杯に詰め込まれているため、フレームワークには一見の価値がある本当に興味深いコンポーネントがいくつかあります。 この入門記事では、構造全体に注意を払いませんが、最も基本的なコンポーネントである
StdLibを強調します。
Webiny stdlib
いいえ、「標準」ではありません。
StdLibは、フレームワークの他のすべてのサブコンポーネントの
StdLibです。 ライブラリは、他のPHPプロジェクトでの依存関係またはSymfony / Yamlの実装と同じ、補助リンクとして機能します。
特に、StdLibは、他の多くの製品と同様に、無料の
オブジェクト指向インターフェイスといくつかのヘルパーメソッドを追加することで、スカラーの操作をはるかに簡単にします。 たとえば、リダイレクト、スキーム、ポートなどを操作するためのいくつかのメソッドを含む軽量の
URLObjectがあります。 このライブラリは、OOラッパーの支援に加えて、基本的な検証、他のWebinyコンポーネントの構築を支援するメソッド、シングルトンを実装するための単純な特性などを提供します。
StdLibの主な違いは、一連の
特性として実装されていることです。これは、現代のPHP開発の非常に過小評価されている部分です。 たとえば、前述の
URLObjectは次のように作成されます。
$this->url('http://www.webiny.com/'); 、StdObject
StdObjectは、この機能を必要とするクラスに追加できるためです。 他のほとんどのWebinyコンポーネントも特性に実装されています。 フレームワークは孤立しているため、チームはこのアプローチを選択して、クラスの階層と機会の拡大を簡素化しました。
StdLibは、Composerから直接
自律的に使用することも、
フレームワーク全体の不可欠な部分として依存関係によってプルすることもできます。 彼女が私たちに何を提供しているか見てみましょうか？
特徴
内部的には、StdLibは2つのサブライブラリで構成されています。 それらの1つ-Exceptionは、追加のWebinyコンポーネントを作成する場合にのみ使用されます。 もう1つは、
StdObjectに説明した機能を含む
StdObjectです。
さらに、ライブラリには、これらのサブライブラリで使用される特性が含まれています。
Componententrait
ComponentTraitは、追加のWebinyコンポーネントを作成する場合にのみ役立ちますが、これはまだ行いません。 スキップしてください。
FactoryLoaderTrait
FactoryLoaderTraitは、動的に定義されたクラスインスタンスの呼び出しに役立ちます。 例：
$className = 'myNameSpace\myClass'; $argument1 = 'Hello'; $argument2 = 'World'; $mustBe = 'myNameSpace\mySubClass';
引数「Hello」および「World」を使用して
myClassクラスをインスタンス化し、それが
mySubClassインスタンスであることを確認するには、次のアプローチを使用できます。
ご覧のとおり、2番目の方法は少し短くなっています。 特に、動的クラス名は誰もが使用するものではないことを考えると、この特性の有用性は自信を刺激しないことに同意しますが、組織/フレームワーク全体の規模を考慮すると、そのような標準化の利点が明らかになります。 この特性を使用するアプローチは、動的クラスのインスタンスを作成するプロセスの単なる「コーディング標準」であり、状況によってはこれが役立つ場合があります。
シングルトン
SingletonTraitはクラスを即座に
シングルトンに変えます。 「シングルトンの悪い性質」については、インターネット上で多くの広範な議論があります-
古代のトピックだけでなく、これ
に関する 私たちの古い議論もあり
ます 。 念のため、通常のDIコンテナを実装することが突然不可能になった場合、この特性が役に立ちます。
ひとつ覚えておいてください
__construct conflicts。 トレイトは
__constructメソッドの実装を実装しません。メソッドの独自の実装を持つクラスと、
他の Singleton 実装を使用するクラスの両方で使用できます。 ただし、この特性を使用する場合は、パターンに従ってクラスコンストラクターを調整する必要があります。
あなたがシングルに慣れていないなら、
この投稿は役に立つかもしれません 。
この実装では、public
initメソッドとprotected
_initメソッドが実装され、インスタンスの作成後にこれらのメソッドがこの順序で実行されることにも注意してください。
これは、コンストラクターに依存せずにSingetonオブジェクトとして将来使用するための初期化後メカニズムとして使用できるため便利です。 おそらくあなたのクラスにはまだ独自のコンストラクタがあり、あなたがする必要があるのはそれをシングルトンに変えることだけですが、そのような魔法にはもう少し微調整が必要です。 この特性は、このような場合に理想的です。
標準ライブラリ
特性は、
StdObjectTraitと
ValidatorTrait組み合わせです。
StdLibTrait自体にはいくつかのJSONエンコード/デコードヘルプ関数が含まれていますが、現時点ではかなり不足しており、他のPHPアナログはJSONでシリアル化する方法を知っています。 おそらくこの場所では、コミュニティによって十分にテストされ、マルチフォーマットをサポートしているコンポーネントであるSymfonyの
Serializerを使用する方が良いでしょう。
ValidatorTrait
まず、
ValidatorTraitは、特性にラップされたPHPネイティブの型チェックメソッドの単純なコレクションです。 私はその有用性と著者が導かれた理由がわからない。 APIはほぼ同じままです（
self::isArray() vs
is_array() ）が、これは何らかの方法でコンポーネントを拡張し、メソッドをオーバーロードし、独自の機能を実装する機能に関連していると思います。
ある場所では、バリデーターは
StdObjectWrapperを使用して、これらのタイプをチェックするためのスムーズなインターフェースを提供します。これは、WebinyがスカラーおよびURLフォーマットのオブジェクト指向ラッパーとして使用するStdObject
StdObject一部です。
StdObjectTrait
これは
StdLibコンポーネントの中核であり、
その主要部分です。 この特性は、
ArrayObject 、
UrlObject 、
StringObject DateTimeObjectなどのクラスを持つ標準クラスの基本的な機能を提供します。
StringObject
おそらく最も簡単な束。 このオブジェクトを使用すると、文字列をオブジェクトとして使用できます。
$string = $this->str("My string");
このインスタンスは、エンコーディング（UFT8エンコーディングのデフォルト）および
length 、
wordCount 、
subStringCountなどの補助メソッド、および
subStringCount PHP関数のラッパーを便利に変更する機能を提供します。 これらはすべて、教室内で手元に置いておくと非常に便利です。 すべての
StdObjectsに共通の
ManipulatorTrait StdObjects 、
StringObjectはそれを変更するメソッドにもアクセスできます。たとえば、文字列を操作するときに最も頻繁に使用される便利な機能は
trimです。
繰り返しますが、特性を操作することの大きな利点は、
stringオブジェクトを介して
stringの呼び出しを実行できることだけでなく、IDEでの自動置換も可能です。
$string = $this->str("This is a string"); echo $string->hash()->padLeft(45, "testing");
そのため、1行でハッシュを取得し、45文字のセットに左側に
testingを追加しました。 そして、ここに結果があります
testif72017485fbf6423499baf9b240daa14f5f095a1 。 上記の例よりもさらに簡単で理解しやすくすることはできません。
別の例として、次のコードを見てください。
$string = new StringObject('Some test string.'); $string->caseUpper()->trimRight('.')->replace(' test');
もちろん、オブジェクトは
__toStringメソッドを実装して、文字列として使用するために直接準備します。 他のすべてのStdLibオブジェクトにも、直接印刷のためにこのメソッドの実装があります。 出口では、いつでもプリミティブを取得してさらに作業を進めることができます。
これらのメソッドは、リストするには多すぎます。 詳細について
は、ソースを参照してください。
配列オブジェクト
StringObjectと同様に、
ArrayObjectは配列を操作するための便利なインターフェイスを提供します。 当然、foreachを使用した反復に適しており、一般に、ネイティブアレイのように動作します。
$array = new ArrayObject(['one', 'two', 'three']); $array->first();
この配列から要素を受け取ると、実際のスカラーではなく、
StdObjectインスタンス
StdObjectれることに注意してください。 戻り値は常に
StdObjectAbstract型に
StdObjectAbstractます。 文字列は
StringObject生成し、配列は
ArrayObject生成します。 数値は多少矛盾している可能性がありますが、
_valueプロパティを
StdObjectWrapperして
StdObjectWrapperインスタンスを生成します。 要素がクラスの場合、このクラスもラップされます。 例：
$array = $this->arr([1, "2", new myClass(1, 2)]); var_dump($array->last());
取得するものは次のとおりです。
私はこれについて自分の気持ちがわからない。 一方で、これは非常に一貫性があり、常に
StdObjectWrapper形で
StdObjectWrapperを取得します。 しかし、一方で、クラスの配列を扱っている場合、ラッパーを忘れて以前と同じように作業することはできません。この側面に注意を払う必要があるたびに。 もちろん、内部に含まれる基本値を引き出す
valメソッドを呼び出すことにより、
StdLibオブジェクトから実際の値を取得する方法があります。
ArrayObjectに基づく配列を使用したさまざまな操作手法については、
対応する特性を参照してください。
key1.key2.key3をインデックスとして指定することで多次元配列に移動できるため、連鎖構文が特に有用であることが
key1.key2.key3ます。これは非常に印象的な時間の節約になります。
$array = [ 'k1' => 'test', 'k2' => [ 'k3' => [ 'k4' => 'deepest' ] ] ]; $a = new ArrayObject($array); $a->key('k2.k3.k4', 'webiny'); $a->key('k2.k3.k5', 'anotherElement'); echo $a->key('k2.k3.k4');
URLObject
このオブジェクトは、URLコードの構文を簡潔にするのに役立ちます。 いくつかの一般的な応答コード、リクエストに署名する方法、ポートおよび他の変数を
操作する方法をサポートし、
簡単に操作することも
できます -スキーム、ホスト、ドメインなどを切り替えます。 信頼できるコードが1行あります。
URLObject StringObjectから継承されないのは奇妙です。 私にとって、継承の存在は理にかなっているでしょう。実際、両者は互いの操作テクニックの恩恵を受けるでしょう。
URLを操作するためのライブラリなどがあるため、この特定の利点は特に見当たりません。 頭に浮かぶ最初の例は、すばらしい
PHPリーグURLライブラリです 。これは、これだけでなく、優れたコード品質を備えており、十数人の高度な資格を持つ開発者によって完全にテストされ、積極的にサポートされています。
DateTimeObject
最後に、
DateTimeObjectます。 これはdatetimeオブジェクトのラッパーであり、より自由で自然な作業用インターフェイスを提供し、時間を操作するときに発生する問題のほとんどを解決するのにも役立ちます。
$dt = new DateTimeObject('3 months ago'); echo $dt;
もちろん、まだTimeで動作するライブラリを使用していない場合は
DateTimeObjectが非常に便利ですが、datetimeでより複雑な操作を行う場合は、
Periodライブラリを少し味付けした
Carbonをお勧めします。
これは、
DateTimeObject完全に役に立たないということではありません-デフォルトでタイムゾーンの操作をサポートし、便利な日付出力形式、
Period代替としてのシンプルで簡単な差分、読み取り可能な「x時間前」、タイムゾーン依存などがあります。
おわりに
このすべてにより、Webinyフレームワークにより、開発者はネイティブPHPコードを使用してプロジェクトに参加できます。 すべてのラッパーは、開発者が期待するとおりに動作します。 野心的すぎる？ おそらく。 しかし、私はこれをプロジェクトの作業を開始する前にコーディング標準を定義する興味深いアプローチだと考えています。これにより、さらなる設計中に発生する問題をなくし、長期的に時間を節約できます。 私が見る唯一の欠点は、StdObjectをサポートしたい個々のクラスでuseを使用する必要があることです。
Webinyプロジェクトは大規模で興味深いものです。 フレームワークは印象的で、そのコンポーネントは広大な領域をカバーしています。 これが本当に必要かどうかの質問は、あなたにお任せします。 なぜ私が彼にそんなに注意を払っていて、なぜこの投稿全体を考えているのか疑問に思っているなら、答えは簡単です-私は新しいもので遊ぶのが好きです。 私は彼らがどのように内部から機能するのか少し興味があります。
後続の投稿では、他のWebinyコンポーネントを調べ、フレームワークを使用してイベント指向アプリケーションの例を作成し、その有効性と柔軟性を評価します。 それまでの間、自分で試してみて、あなたの経験について教えてください。