最近、ある種のWebアプリケーションの開発を任されました。 詳細には触れませんが、アプリケーションは輸送計画に関連しているとだけ言います。 サイトへの訪問者が使用できる公開部分があります。 システムオペレータ用の内部インターフェイスがあります。 サードパーティのサイトに投稿するためのインフォーマーがあります。 技術的な観点から見ると、これらは数十のスクリーン、多くの異なる形式、プレートです。 一部の画面では、ajax、javascriptで記述されたカスタムコンポーネント、およびドラッグアンドドロップなどのあらゆる種類のかわいらしさを使用しています。 データは、通常どおり、1ダースのテーブルの形式でリレーショナルデータベースに保存されます。 一般的に、これは非常に原始的なアプリケーションではありませんが、私はそれを非常に難しいとは言えません。
職場では、そのようなアプリケーションを設計するか、個人的にコーディングする必要があります。 ただし、このプロジェクトには1つの重要な要件がありました。 アプリケーションは、真剣で実績のあるプラットフォーム、つまりZend Frameworkに基づいて開発する必要があります。 自作の「自転車」の使用は受け入れられません。 率直に言って、私はまだZend Frameworkの実際の経験がありません。 しかし、このプラットフォームは有名で、その背後には有名な開発者がいます。 多くの開発者によって、Zend Frameworkは一般にWeb開発標準と見なされています。 それで、さらに、新しくて堅実な何かを学ぶ理由があります。 したがって、私はこのプロジェクトを熱心に取り上げました。
以下は私の個人的な感情と印象の説明ですので、おそらくあなたはそれらをあまりにも近づかないでください。 これは、プロジェクトの作業が完了した後に残った感情的な残骸です。 私は初めて商用プロジェクトでZend Frameworkを使用しました。
Zend Frameworkは、Webアプリケーションを開発するための優れた、考え抜かれた便利なプラットフォームとして位置付けられています。 私の意見では、典型的なWebアプリケーションとは何ですか？ まあ、これらは多くの異なるスクリーン、多くの形、多くのプレートです。 これはすべて、データベース、通常はリレーショナルデータベースで積極的に機能します。 さて、MySQLの場合の95％で、より具体的になります。 したがって、Webアプリケーションを開発するためのプラットフォームから、フォーム、さまざまな画面、およびリレーショナルデータベースを使用した便利な作業を作成する良い機会を少なくとも期待しています。 そして、私はマスターし始めました。
私が最初にやらなければならないことは、Zend Framework自体の基本を学ぶことでした。 このプラットフォーム専用の本「
Zend Framework 」を読みました
。 PHP Webアプリケーション開発。 Vikram Vaswaniにより投稿 。” 現時点では、このようなフレームワークに関するロシア語版の書籍はほとんど出版されていないようです。 原則として、この本は非常に優れています。 それを読んだ後、私はフレームワークを操作する方法の一般的な理解がありました。 次に、ギャップを埋め、このフレームワークが他に何を提供できるかを一般的に理解するために、公式文書を研究し始めました。 結局のところ、本はエンジンのすべての機能を考慮していません。 包括的でわかりやすく書かれた公式ドキュメントは、
framework.zend.com / manual / ruにあります。約1週間後、アプリケーションの開発を開始できると判断しました。
コーディングに関する私の世界観
製品がどのように書かれるべきかについての私の個人的な意見についてのいくつかの言葉。 ここで、彼らが時々私を批判するようなことについても言及します。
OOPとOOPパターンの使用を尊重します。 ただし、アプリケーションを正当化し、コードを読みやすくするか、そのさらなる改善を本当に簡素化する必要があります。 パターンのためのパターンは悪いです。
良いコードは明確なコードです。 明確なコードは簡潔なコードです。 短いコードを書くことができれば、原則として理解しやすくなります。 1つのモニター画面に収まる、より論理的に接続されたコードの断片は、より優れています。
既存のソリューションやアプローチで何かが私に合わない場合は、もっと満足できる独自のソリューションを作成することを考えます。 はい、多くの人がそれを「自転車の発明」と呼んでいます。 しかし、私は長くて悲しくて他の誰かのファイルを提出するのではなく、快適なファイルを作成することを好みます。
MVCは優れていますが、いずれの場合も開発プロセスを簡素化および高速化するわけではありません。 場合によっては、特に単純なアクションに関しては、それから逸脱することができますが、これらのアクションがたくさんあります。 （しかし、MVCはまったく必要ないとは言いたくありません。）以下に例を示します。
if(@$_POST['action'] == 'done') { $dbi->exec(“UPDATE bug SET status='done' WHERE id=:bugId“, array('bugId'=>$bugid)); $message = “Status changed to <b>Done</b>”; } elseif(@$_POST['action'] == 'delete') {
はい、モデル、コントローラー、ルーター、ビューをここに混在させました。 それはgovnokodの一部のように見えます。 しかし、いくつかの意図的なケースでは、費やされた時間、コードの量、およびさらなるサポートの可能性の観点から正当化される場合、そのように書きます。 一般的に、私は熱心なMVC狂信に反対し、常識と思慮深いアプローチに賛成です。
もちろん、この記事で言及されているプロジェクトには、そのようなコードはありません。 私は、Zend Framworkによって指示されたアプローチから意識的に逸脱するのに十分な経験をすでに持っているとは思わないので、そのコンセプトに完全に従うことを試みました。
Webプロジェクトのテンプレートについて少し説明します。 Smartyなどのテンプレート言語がいつ使用されるかわかりません。 さて、なぜ本格的なPHP言語が存在するのに、一般的に制限された新しい言語を発明するのでしょうか？ レイアウトデザイナーがPHP shny if（...）とforeach（...）の使用方法を学ぶのは本当に難しいですか？ Smartyほど複雑ではありませんが、新しいエキゾチックな言語をプロジェクトに追加しません。
ところで、テンプレート（またはビュー）は非常に複雑であるため、ifおよびforeachだけでなく、相互に継承されるクラスやオブジェクトなどの非常に複雑な構造も使用する必要があります。 同時に、プレゼンテーションのタスクは同じままです-ドライデータからHTMLコードを生成します。
一般に、テンプレートについては、私は常に通常のPHPを好み、開発者がテンプレートにロジックをプッシュしないことを約束します。 テンプレートを処理するには、タイプの最も単純な関数を使用できます
function renderTemplate($file, $vars) { foreach($vars as $_name => $_var) { $$_name = $_var; } require $file; }
さらに、もちろん、シールド、キャッシングのための最も簡単なバインディング。 幸せに必要なものは他にないようです。
おそらく、テンプレート言語としてのXSLTに反対するものはまだありません。 ただし、情報を提示するためのオプションが多くなく、比較的単純な場合のみです。 さて、受信したデータに完全に依存しているある種の地獄のような構造とジオメトリのベアXSLTテンプレートを簡単に作成することはできません。 ここでは、サイクルとオブジェクト、およびポリモーフィズムと継承の両方が必要です。
Zend Frameworkをインストールする
判明したとおり、このフレームワークの重量は約25MBで、約3,000個のファイルが含まれています。 弱くない、と思った！ どうやら、あなたは夢を見ることができるだけであることがすべて理解されています！
まず、Zend Frameworkベースのアプリケーションのディレクトリ構造は、私にとって少しイライラさせられました。 非常に多数のディレクトリが含まれます。 プロジェクトに取り組んでいるとき、私はこの構造で常に失われていました。 また、作成されたクラスの名前の規則、ファイルの命名規則、およびそれらの配置方法は、一時的すぎるように思えました。 それらにはロジックがありますが、正直に言うと、これはすべてより直感的に行うことができます。 また、提出スクリプトのディレクトリを移動するのは特に面倒です。 どうやら、このフレームワークを長時間使用していると、慣れるでしょう。
しかし、アプリケーションの新しいセクションを作成する儀式に非常にうんざりしていました。ディレクトリを作成し、ファイルに名前を付け、クラスに名前を付け、コントローラーに名前を付けます。 まずコントローラーでこれを行い、次にビューでこれを行います。 はい。コンソールユーティリティがあり、場合によってはこれを自動的に行うことができます。 しかし、多くの場合、それは無能です。
Zend Frameworkは、共有ホスティングで動作するようには設計されていないことが判明しました。 開始するには、プロジェクトのルートとは異なるディレクトリをVirtualHostに登録する必要があります。 したがって、少なくともVDSサーバーが必要です。 ええ、そうです、共有ホスティングで機能するものを開発しているのなら、あなたはクールではなく、専門家の間には居場所がないという意見を聞きました。 私は常に、すべてのWebプロジェクトの95％が共有ホスティングでスピンしていると考えていましたが。 さて、とにかく、ファイルを数回ストロークした後でも、シャードのホットアップを行うプロジェクトがありました。
データベースを操作する
最初に、データモデルを作成する必要がありました（MVCコンセプトの一部として）。 結局のところ、Zend Frameworkはモデルを作成する準備が整ったものを何も提供していません。 実際、独自のクラスを作成するだけで、そのメソッドがデータベースの操作でこれまたはその操作を実行します。 つまり 場合によっては、モデルクラスはSQLクエリの単なるラッパーであり、PHPバインディングが追加されたSQLクエリの場合もあります。
データベースを操作するために、フレームワークはZend_Dbコンポーネントを使用します。 SQLを介して最も一般的なDBMSで作業できます。
また、SQLを使用せずにクエリを作成できます。また、フレームワーク内でSQLに変わるトリッキーなオブジェクトを作成することもできます。 多かれ少なかれ複雑なクエリを作成するためには、このラッパーを構築するよりもSQLクエリを作成する方が便利で簡単であるように思えます。これにより、複雑なクエリを作成できなくなります。 一般に、フレームワークを形成するように強制するよりも、SQL自体をよく研究し、最適な方法でSQLを実行することを期待する方がよいと考えています。 ネイティブSQLは読みやすく、すべてのプログラマーが理解しやすく、特定のDBMSのすべての機能を使用できます。 オブジェクトクエリデザイナーを使用すると、特定のデータベースの方言から抽象化できると言いますか？ 複雑なクエリの場合-クールなコンストラクタを使用しても、常に抽象化することは不可能です。 さて、もう1つの議論-DBMSを変更する必要がある単一のプロジェクトを覚えていませんが、同時にプロジェクト全体、ビジネスロジック、データモデルのグローバルな変更はありませんでした。 以前のプロジェクトに基づいて完全に新しいプロジェクトを作成します。 以前のバージョンのデータモデルクラスの一部を一般的なバックグラウンドに対して保存しても、作業はそれほど楽になりません。
それでは、Zend FrameworkでのSQLの操作はどのようなものですか？ さて、このようなもの：
$ result = $ db-> fetchAssoc（ 'SELECT * FROM items WHERE age> 18'）;
そして、$の結果を使用して、テーブル形式の連想配列を操作できます（ただし、これは配列ではありません）。これは非常に便利です。 配列をさらに処理するために渡すことも、表示のためにビューに直接渡すこともできます。
SQLクエリの結果を抽出する、さらに便利なメソッドがいくつかあります。
fetchCol（）-単一の列を取得します。 ID shekのリストを取得する必要がある場合に便利
fetchRow（）-最初の行を取得します。 主キーで1つのエントリを選択する必要がある場合に便利です。
fetchOne（）-1つの値のみを取得します。 また、本当に1つの値を取得する必要があり、配列から1つの要素を選択するコードを書きたくない場合にも便利です。
fetchPairs（）-値のペアを連想配列として取得します。 キーと値のハッシュを作成します。 異なる辞書を作成すると非常に便利です。
これらのすべての方法により、コードの行数を簡単に減らすことができます。 あらゆる種類の追加ループ、要素の抽出などを削除します。 その結果、モデル内のコードの大部分が大幅に削減されます。
fetchPairs（）メソッドが適しています。 そして、データベースの主キーがキーとして使用され、データベースの配列レコードが値として使用される、もう少し興味深く必要な辞書をどのように取得しますか？ 非常に一般的なタスク。 答えは何もない！ それを手で行い、fetchAssoc（）を呼び出し、ループを回して新しい辞書配列を生成します。 残念です！
では、先に進みましょう。 テーブルからデータを抽出し、それらからツリーのような配列を作成する必要があります。 この一般的な操作もまったく実装されていないことがわかります。 つまり 次のようなものはありません：
$ hierarhy = db-> fetch_tree（ "SELECT id、parent_id、title FROM tree '、' id '、' parent_id '）;
どうぞ SQLでは、パラメーターを渡す必要があります。 まあ、はい、一見、すべてが簡単です。 これは次のように行われます。
$ result = $ db-> fetchAssoc（ 'SELECT * FROMニュースWHERE id =？'、7）;
いくつかのプレースホルダーを配置することもできます。
$ result = $ db-> fetchAssoc（ 'SELECT * FROM news WHERE chapter =？AND type =？'、array（2、8））;
現在、プログラムが複雑になると、クエリの複雑さが増し、すでに多数のパラメーターが存在する可能性があります。 名前付きプレースホルダーが必要です。 シリアル番号でプレースホルダーを数えることは、コードのわかりやすさを助長するものではありません。 結局のところ、Zend Frameworkはそれらを実装していません！ これらは機能しますが、選択したデータベースがそれらをサポートしている場合のみです。 たとえば、MySQLiを選択した場合、名前付きプレースホルダーで作業することはできません。 名前付きパラメーターをエミュレートするのは本当に大変でしたか？！ さて、このことは解決可能であることが判明しました。 アダプターとしてMysqliではなくPdo_Mysqlを選択すると、名前付きパラメーターが機能し始めることがわかりました。 PDO自体の内部でエミュレートされます。 率直に言って、私はすぐにこれに到達しませんでした。 in辱は収まったが、不快な後味が残った。
多くの場合、SQLクエリではこのようなコードを使用する必要があります
SELECT * FROMアイテムWHERE id IN（1,3,5,8,12）
id-listは配列から動的に生成されます。
私は個人的に、Zend Frameworkでこれを美しく行う方法を見つけていません。 特定のquoteInto（）メソッドがあります。 このように使用できます
$ sql = $ db-> quoteInto（ "SELECT * FROM item WHERE id = IN（？）"、array（1,3,5,8,12）））;
クエリで名前付きパラメーターを使用できず、いくつかの部分から複雑なクエリをコンパイルできないことに耐えましたが、必要なSQLコードを取得しました。 配列が空であることが判明した場合にのみ、構文エラーが発生します。これは、SQLによってSELECT * FROMアイテムWHERE id = IN（）になるためです。
したがって、すべてをif（count（$ idList）> 0）でラップするか、毎回、意図的に無効な識別子（たとえば、-1）を配列に追加します。 Krivenko、しかし解決策。 しかし、とにかく、それは判明しましたか？ 文字列を連結することによってのみ複雑なSQLクエリを作成できること。 また、SQLクエリは、PHPを埋め込まずに単一のコードとして表示することを好みます。 それに、HTMLとPHPを混ぜることは悪いと考えられますが、SQLとPHPは問題ありません。
一般的に、Zend_Dbは私をあまり好きではありませんでした。 私はその使用から大きな利点や強い利便性に気づきませんでした。 ちなみに、Zend_Dbの重量は500KB以上です。
一般に、データベースを操作するには、次のパブリックメソッドを使用して自家製の小さなクラスを使用することを好みます。
connect（$ config）-データベースに接続します
fetchTable（$ sql、$ params）-レコードの配列を返します
fetchRow（$ sql、$ params）-1つのレコードを返します
fetchCol（$ sql、$ params）-単一の列を返します
fetchOne（$ sql、$ params）-スカラー値を返します
fetchPairs（$ sql、$ key、$ value、$ params）-配列キーを返します-値
fetchDict（$ sql、$ key、$ params）-配列キーを返します-レコード
fetchTree（$ sql、$ key、$ parent、$ params）-ツリーを返します
exec（$ sql、$ params）-非選択クエリを実行します
getInsertId（）-最後に生成された自動インクリメントを返します
getAffectedRows（）-変更されたレコードの数を返します
実行結果は、各ケースの論理構造の通常の連想配列です。 パラメータには常に名前が付けられ、数値、文字列、リストを渡すことができます。 SQLで構文エラーが発生した場合、クラスは例外をスローします。 この「バイク」の重量は10KB程度で、率直に言って、私にとっては常に十分です。 他のプログラマーはそれを勉強するのに10分を必要とし、Zend_Dbを勉強するにはマニュアルを注意深く勉強するのに何時間もかかりますが、まだ質問があります。 クラスを拡張し、いくつかの仮想メソッドをオーバーライドすることにより、他のデータベースのサポートを追加できます。
フォーム
Webアプリケーションで次に重要なのはフォームです。 通常、それらの多くがあります。 構造と外観も非常に多様です。 Zend FrameworkはZend_Formを使用してフォームを操作します。
フォームを作成するには、フォームオブジェクトを作成する必要があります。 各フィールドのオブジェクトを追加する必要があります。 フィールドでは、さまざまなパラメーターを構成できます。 バリデーターなどを指定します 以下はフィールドを作成する例です
$username = new Zend_Form_Element_Text('username'); $username ->addValidator('alnum') ->addValidator('regex', false, array('/^[az]+/')) ->addValidator('stringLength', false, array(6, 20)) ->setRequired(true) ->addFilter('StringToLower');
すべてのフィールドを作成したら、それらをフォームオブジェクトに追加します。
$form ->setAction('/somepath') ->setMethod('post') ->addElement($name) ->addElement($company) ->addElement($email) ->addElement($phone) ->addElement($action);
たくさんのフィールドがある場合にのみ、それらのいくつかをフォームに追加することを忘れます。 ええと、コードに何かをリストする必要があるとき、そしてどこか他の場所にすべてをリストするために再びどこか別の場所に置く必要があるとき、私は恐怖を嫌います。 そして、ここでは毎回フィールドオブジェクトの変数の名前と出力用の名前を示す必要があります
addElement（）がフォームへのリンクではなく、追加された要素へのリンクを返した場合、流れるようなインターフェースを使用すると、コードははるかに簡潔になり、繰り返しもなくなります。 そのように
$form->addElement(new Zend_Form_Element_Text('username')) ->setRequired(true) ->addValidator('regex', false, array('/^[az]+/'));
しかし、それは不可能です！
お気づきのように、ここでは既製のフィールドバリデータを使用できます。 悪くない。 電子メールを入力するフィールドを作成して、曲線の電子メールアドレスを入力してみましょう。 これを行うには、標準のEmailAddressバリデーターを使用します。
曲線の「xxx」メールを指定してみましょう。 エラーメッセージが表示されます。
「xxx」は、local-part @ hostnameという基本形式の有効なメールアドレスではありませんわかった もちろん、メッセージをロシア語に翻訳する必要がありますが、簡単に行うことができます。 そして、さらに湾曲したアドレス「i@_domain.xx」を試してみましょう。
そして、ここに私たちが得るものがあります：
「_domain.xx」はメールアドレス「i@_domain.xx」の有効なホスト名ではありません
「_domain.xx」はDNSホスト名のように見えますが、TLDを既知のリストと一致させることはできません
「_domain.xx」は有効なローカルネットワーク名ではないようです
「i」はドットアトム形式と照合できません
「i」は引用符付き文字列形式と照合できません
「i」はメールアドレス「i@_domain.xx」の有効なローカル部分ではありません6件の投稿！ 誰がこれを必要としますか？ 平均的なユーザーは、TLD、引用符付き文字列またはドットアトムが何であるかを本当に理解していますか？ 平均的なユーザーが必要とするメッセージは「Invalid E-mail」1つだけです。 ただし、標準ツールではこれが許可されていません。 このメッセージのヒープの出力を取り除くために、独自のバリデータクラスを作成することをお勧めします。
さて、すべてのフィールド、すべてのバリデーターを設定したフォームを作成したとしましょう。 今それを出してください。 デフォルトでは、フォームのHTMLコードは次のようになります。
<dl class="zend_form"> <dt id="phone-label"> <label for="phone" class="required"></label> </dt> <dd id="phone-element"> <input type="text" name="phone" id="phone" value=""> <ul class="errors"><li> </li></ul> </dd> ... </dl>
さらに、隠しフィールドもDD要素でラップされます！ そして、私たちはフォームにどのような奇妙なボイドが形成されたのか疑問に思い始めます。 一般に、フレームワークには、非表示フィールドの特別な処理のためのインテリジェンスがありません。
しかし、最も単純なDLリストが私に合わない場合はどうでしょうか？ 突然、複雑な構造のフォームを作成する必要がありますか？ ここでは、デコレータクラスを使用することが提案されています。 デコレータは、特定のHTMLタグでフォーム要素をラップできるクラスです。たとえば、DTタグではなく、DIVなどで要素をラップできます。 怖い！ 「正しい」MVCフレームワークにより、コントローラー内で直接、最も読みにくい方法でレイアウトを行う必要があります。
私の意見では、非標準フォームの組版はタイプセッターのみが行うべきです。 フォームのすべてのレイアウトを含むビュースクリプトを作成するだけです。 そして、コントローラー内で数十のクラスのデコレーターを使用することは、控えめに言っても曲がっています。
フォームを操作するための最も単純な「自転車」の例を挙げましょう。これにより、フォームを簡潔かつ便利に作成できます。
フォームの構成：
$form = new UniversalForm(array( 'name' => array('label'=>'', 'required'=>true), 'email' => array('label'=>'', 'type'=>'email'), 'birthday' => array('label'=>' ', 'type'=>'date'), 'sex' => array('label'=>'', 'type'=>'choice', 'items'=>array('m'=>'', 'f'=>'')), 'code' => array('label'=>'', 'regExp'=>'/^\d{6}$/', 'regExpMessage'=>' ', 'value'=>'000000'), 'action' => array('type'=>'hidden', 'value'=>'updateInfo'), ));
ここでは、コードの量を減らすために、フォーム要素のオブジェクトを明示的に作成する代わりに、単純に構成配列を作成することができます。 これは、フィールドオブジェクトとバリデータを手動で作成する可能性を排除するものではありませんが。 それでは、次の形式を使用します。
$ form-> setFromPost（）; // POSTからデータを設定します
$ form-> isValid（）; //データが有効であることを確認します。 そうでない場合、フォーム送信スクリプトが出力するエラーメッセージがインストールされます。
$ data = $ form-> getValues（）; //値を取得します
$ form-> setValues（$ data）; //フィールド値を設定します。 コンストラクターで混乱する配列を介して同じことを行うことは可能ですが
$ form-> render（ 'form.tpl.php'）; // HTMLを生成します。 テンプレートが指定されていない場合、デフォルトのテンプレートが使用されます。
$ form-> renderJs（）; //クライアント側のPHPバリデータを複製するJavaScriptバリデータを生成します。
さて、MVCの観点からは間違っているいくつかのメソッドがあります。
$ form-> getSqlSet（）; // SQLコードの一部を返します
そのように使用できます
$ sql =“ UPDATE account SET”。$ form-> getSqlSet（）。” WHERE id = 777”;
次のメソッドは同じ目的で使用されます。
$ form-> getSqlFieldsList（）;
$ form-> getSqlValuesList（）;
はい、これは完全に標準的な正しい決定ではありません。 しかし、その後、フィールドのセットはフォームコンストラクターで一度だけ記述する必要があります。 変更すると、すべてのSQLクエリが自動的に変更されます。
管理者
原則として、複雑なWebアプリケーションでは、管理パネルまたはコントロールパネルを作成する必要があります。 たとえば、パラメータの設定、ディレクトリの編集など。 つまり 少なくとも、レコードリストエディタを作成するためのツールが必要です。 少なくともフラットなリスト、および複雑なプロジェクトの場合、これらのリストは多くの場合階層的でなければなりません。
一般に、このフレームワークではこれに対応する準備はできていません。 必要に応じて、すべてを手動で実装する必要があります。 つまり 各エディターで、テーブルとフォームを含む画面を作成し、実際に手動でCRUD操作を実装します。
結論と印象
ご理解のとおり、この「正しい」フレームワークは私にはあまり良い印象を与えませんでした。
しかし、おそらくZend Framworkは次の場合でも習得できます。
1.アプリケーションの許容できるフレームワークを作成するのに十分な経験がない場合。
2. MVCの操作方法がまったくわからないが、このイデオロギーを体験したい場合
3. OOPと典型的な設計パターンの適用について十分に理解していない場合、Zend Framworkは多くの例を示します。 そこでは、OOPが必要な場所と必要でない場所で使用されました。
4.また、Zend Framworkは、データベースからデータを抽出して画面に表示するだけの作業ではない単純なアプリケーションを作成すれば、正常に機能します。 たとえば、一部のニュースポータルや製品カタログ。
ただし、他のフレームワークに目を向ける方が良いでしょうか？ Zend Frameworkはすでに地盤を失い始めており、おそらく正当な理由があります。
そして、個人的に、私が作業しようとしたフレームワークのほとんどすべてのコンポーネントで不便に遭遇しました。
「もっと便利にできたはず！」や「まあ、どうしてこんなことに気付かなかったの！」 Zend Framwork開発者の主な仕事は、OOPnoをすべて行うことであるという印象を受けました。可能なことはすべて、すべてラッパー、アダプターにラップされており、便利かどうかは関係ありません。ライブラリの抽象化のレベルは非常に高いため、理解するのが困難です。そして最も重要なことは、ほとんどすべてのコンポーネントをニーズに合わせて仕上げる必要があることです。そのままの形では、すべてが期待どおりに機能しません。はい、よく知っています。確かに私はフレームワークで何かを誤解しました。確かにマニュアルに何かが欠けていた。そして今、私はRTFMスタイルのコメントを取得します。しかし、これは指標でもあります。優れたプラットフォームを簡単かつ迅速に習得し、すぐに適切で便利なソリューションを示す必要があります。ここでは、私はそれを感じませんでした。ソビエトのジョークも思い出しました。図面に従って飛行機を集めると、蒸気機関車であることがわかりました。そして、図面には、「結果の製品-ファイルを修正する」と書かれていました。エンジンをファイルで飛行機に変更したくありません。箱から出してすぐにすべてが適切に機能するようにします。PS：誰かの「宗教的感情」を傷つけた場合、事前に謝罪します。PS2。：この記事は、Zend Frameworkについて書かれています。そして、これはMVCのメリットに挑戦する試みではありませんが、残念ながら多くの人々がそのように考えました。