web-dev-qa-db-ja.com

WordPress MVCに準拠していますか？

WordPress=ブログプラットフォーム、CMSと考える人もいれば、WordPressを開発フレームワークと呼ぶ人もいます。 WordPress MVCに準拠していますか？

私はフォーラムを読みましたが、約3年前に誰かがMVCについて尋ねました。いくつかの肯定的な答えと、いくつかの否定的な答えがありました。 MVCが何であるかを誰も正確に知らず、誰もがそれを独自の方法で考えていますが、すべての議論に存在する一般的な概念がまだあります。

私はMVCフレームワークの経験がほとんどなく、フレームワーク自体については何もしていないようです。 MVCのほとんどはプログラマーによって行われます。さて、WordPressに戻って、コアの書き換えエンジン（WP_Rewrite）をコントローラーと見なしてもよいでしょうか？モデルとしてのクエリとプラグインロジックビューとしてのテーマは？それとも私はそれをすべて間違っていますか？

ありがとう;）

model-view-controllerwordpress
63
kovshenin

Wordpress自体はMVCで設計されていませんが、フレームワーク内で非常にMVC指向のテーマとプラグインを構築できます。役立つツールがいくつかあります。

WordPress MVCソリューション：

WordPress.org Ideas and TracのMVCスレッド：

46
user239974

Wordpressは、ちょっとしたMVCです。どちらかと言えば、ビューがモデルからデータを「プル」するプル型MVCレイアウトです。これは、多くの異なるオブジェクトを使用する代わりに、非常に進歩的な方法でこれを行いますが、実際には、フロントエンドテンプレートを多くの方法で記述しやすくします。

また、これにより、ビューにある程度のコントローラーロジックが与えられます（したがって、ちょっとしたMVC）。

これを実行してみましょう：Wordpress=はURLを取得します。wordpressコアはコントローラーとして機能し、データベースの実行する最初のクエリを決定します。どのビューをロードする必要があるか（カテゴリビュー、単一投稿またはページビューなど）次に、そのINTIALクエリ応答をパッケージ化し、ビューファイルに送信します。

そのビューファイルは、厳密な表示専用ファイルにすることができますORそれは、組み込みのもの以外の追加情報/クエリを要求できます。これは、ビューがデータをプルするMVCのプルタイプです。コントローラーの代わりに、モデルからビューにデータを「プッシュ」します。

したがって、サイドバーまたはウィジェット領域をロードするコードをビューが見ると、ビューはその情報を要求します。ただし、存在するウィジェットはコントローラーによって決定されます。コントローラーは、サイドバーにあるウィジェットをモデルで確認し、現在のページに表示するように設定されているウィジェットを選択して、ビューに返します。

その各部分がオブジェクトではないということは、MVCをこれより少なくするわけではありません。テーマについて何も変更せずに、WP coreを変更できます。同様に、 'get_pages（）'などの組み込み関数を使用する限り、モデルとデータベーステーブルは次のように変更できます。したがって、モデルはビューから独立しており、コントローラーも独立しています（ビューがコントローラーロジックを追加して、コアが通常行う以上のことを行う場合を除く）。

WPModel :: get_pages（ 'blah blah'）のような多くのメソッドやものを保持するモデルオブジェクトがあり、そのようにすべてを含むことができますが、懸念事項の根本的な分離がまだあります。

ビュー：テンプレートファイルコントローラー：WP coreモデル：特定のデータ処理を処理するさまざまな関数。

名前、引数などが同じである限り（または単に新しいものが追加されている限り）、懸念の分離が維持され、他の人を混乱させることなく変更できます。

MVCのスーパークリーンバージョンではありません（特にフックが関与する場合）が、基本的なレベルではそこから始まります。

そして、それについて進んでいるのは悪いことではありませんIMO。ウェブサイトからのリクエストは本質的に進行的です：それは明確な始まりと終わりを持つプロセスであり、リクエストを処理し、データを取得し、それをパッケージ化し、そして死ぬための手順が必要です。これらのステップは、オブジェクトとオブジェクトメソッドおよびOOPレイアウト（いくつかの作業を簡単にする）を使用してセットアップできます。または、多くの関数呼び出しを記述し、それらを分離することができます。プライベート変数はそのように失われますが、アプリケーションのニーズによっては...気にしないかもしれません。

開発を一方向に行う方法はなく、WPはWebサイトの20％程度に位置しているため、適切に処理されています。おそらく処理しないことデータベースに「ページxの子ページ」という質問に答えてもらい、そのデータを処理するために、複雑なクラス階層を学習/記憶する必要があります。OOPで簡単にできますか？はい、しかしJoomlaがあればOOPを使用して複雑なカスタムWebサイトを実装するのがいかに難しいかの例は、WPはFARより簡単かつ迅速で、時間はお金です。

24
Rampant

コメントですでに述べたように、MVCは特定のフレームワークではなく、アーキテクチャ設計パターンであり、いいえ、WordpressはMVCパターンに従いません。

プログラミングロジックからビュー（テンプレート）が分離されていますが、管理パネルではなくフロントエンドのみであり、ビューとアプリケーションロジックの一般的な分離は必然的にMVCではありません。 MVCパターンの実装は通常、その背後にあるオブジェクト指向プログラミングパラダイムを想定しており、Wordpressは主に手続き型の方法で実装されます。 PHP関数、したがって実際のモデルもありません。

9
Daff

WordPress=に関連するディスカッションで定期的に取り上げられるトピックの1つは、WordPressおよびMVC。

ただし、MVCは、Web開発の特効薬ではないということです。はい、それは素晴らしいデザインパターンであり、個人的にはグローブのようなWebアプリケーションモデルに適合すると思いますが、すべてのフレームワークまたはプラットフォームがそのデザインパターンを実装するわけではありません。

適切なケース：WordPressはMVCではありません。

そしてそれは大丈夫です。特に、パターンWordPress=が提供するだけでなく、正しく活用されるとうまく機能する場合は、プロジェクトに足を踏み入れたいという欲求を捨てる必要があると思います。

「でもMVCが大好き！」

私もそうです！実際、去年は多かれ少なかれMVCアーキテクチャを模倣したプロジェクトに取り組んできました。 MVCの高レベルの例。

enter image description here

MVCの高レベルの例。

例えば：

Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.

最後に、一連の書き換えルールにより、アプリケーションに/ people/update/1または/ people/allの形式の予測可能なURLのクリーンなセットが提供されました。どのパターンがWordPress=実装しますか？

WordPressは、イベント駆動型アーキテクチャ（Observerパターンなど、いくつかのバリエーションがあります）を実装しています。

要するに、概念的にこれを次のように考えることができます。

Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.

複雑すぎませんか？イベント駆動型パターンの高レベルの例 enter image description here イベント駆動型パターンの高レベルの例

あなたが望んでいるように機能させようとするのではなく、機能するパラダイムの観点から考え始めると、解放されます。問題をより簡単に解決するのに役立ちます。

一番下の行は次のとおりです。WordPressはイベント駆動型のデザインパターンを実装するため、MVCを実装しようとしても、フックシステムを利用する必要があります。

注意を怠ると、実際に作業を完了することなく、完璧なアーキテクチャを作成しようとすることになり、ソフトウェアの雰囲気に身を任せて、事実上、宇宙飛行士になることができます。あなたはデザインパターンを避けると言っていますか？

どういたしまして！デザインパターンは、他の何よりも基本的に、以前かつ一般的に解決された問題の解決策を基本的に提供するため、目的に役立ちます。それらを使用してください！

しかし、私がやろうとしているのは、パターンが好きだからといって、パターンに合わせるように強制する必要がないということです。それは彼らの目的ではありません。代わりに、選択したプラットフォームが実装するプライマリパターン（この場合はイベント駆動型パターン）を活用し、適切なパターン（依存関係の注入など）を実装します。

それ以外の場合は、足を手袋に入れようとしているようなものです。

礼儀（および完全にコピー：P）から： http://tommcfarlin.com/wordpress-and-mvc/

5
Rahul Balakrishna

これを検索エンジンからヒットする人々のためのより最近の情報で更新するために-wp-mvcプラグイン http://wordpress.org/extend/plugins/wp-mvc/ は作成に大いに役立ちますプラグイン開発用のmvcフレームワーク。詳細はこちらをご覧ください： http://wpmvc.org/documentation/70/tutorial/

5
Dave Amphlett

オプションのリストに追加するだけです（著者として明らかに偏見があります） swpMVC は、Rails、Sinatra、Express、およびFuelPHPに触発された、フル機能の軽量MVCフレームワークです。それは徹底的に文書化されており、 wp-mvc を使用して楽しんでいる間に、モデルが対話するためのフォームコントロールなど、モデルがビュー自体を生成できるものが必要でした。

WordPressの上にアプリを配置するために必要なコントローラーコードの量を減らすためにこれを大幅に組み合わせた結果、WordPress内で実行される非常に高速で効果的なフレームワークが得られました。モデルは PHP Activerecord に基づいており、既存のWordPress Post、PostMeta、User、UserMeta、Termなどのデータ型を含む8つのモデルが含まれています。 activerecordライブラリのおかげで、データのモデリングは非常に簡単です。これまで、このフレームワークでの作業は非常に楽しかったです。

アンダースコアPHPおよびPHP QuickProfiler（FuelPHPで見られるように。）

4
Brian Zeligson

RokkoMVC は、特にWordPress用に構築されたマイクロMVCフレームワークです。このプロジェクトは、AJAX機能をWordPressアプリケーションで簡素化するだけでなく、モデル、ビュー、およびコントローラーをテーマに使用する他のすべての利点をもたらすことを目的としています。 。

2
rodrigo-silveira

私は最近、シンプルなView-Controllerシステムを利用するプラグインを作成するのに苦労しましたが、結果がとても気に入ったので、テンプレートを分離しました 独自のリポジトリに 。オブジェクトベースのコントローラを提供し、変数をローカルでPHPテンプレート、テンプレートフラグメント（テンプレート内のテンプレート）およびコンポーネント（独自のサブコントローラを持つテンプレートフラグメント）に渡します。すべて2つの小さなクラスです！

もちろん、他のWP開発者は;-)。

1
halfer

Mvcとはほど遠い、一部の人が言うように、MVCであるかどうかにかかわらず、ちょっとしたことはありません...ビューレベルでロジックを記述するという事実は、mvcフレームワークとしてそれを限定しません。人々がそれを使用する理由-それは学ぶのは簡単です、あなたは筋金入りのPHPプログラマである必要はありません、彼らは怠け者です。

0
lokers