モジュール/プラグインをサポートしながら、MVCフレームワークをどのように整理しますか？[閉まっている]

MVCフレームワークに関しては、主に2つのコードベース構造があります。問題は、両者に組織的なバグがあるように見えることです。

標準MVC

/controller
/model
/view

問題：関連するコンポーネント（フォーラム、ブログ、ユーザーなど）の分離がない

モジュラーMVC

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

モジュールベースのシステムを選択すると、問題が残ります。

• 長い名前（Forum_Model_Forum = forum / model / forum.php）（Zendのように）
• ファイルシステムis_file()は、フォーラムモデルを持つフォルダーを見つけるために使用しますか？（小花のように）

異なるモジュールを分離しようとしたときにうまく機能する他のMVC構造はありますか？私が見逃しているこれらの構造の利点はありますか？

試してください：

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

モデルはアプリケーションの中心です。スタンドアロンパッケージとして設計およびコーディングする必要があります。コントローラーはモデルのクライアントにすぎず、ユーザーのアクティビティをモデルのアクションに変換します。ビューは、モデルのデータを表示する特定の方法の1つにすぎません。アプリケーションが大きくなったら、さらにクライアントをモデルから分離することができます。

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

これにより、複数のクライアントを使用できること、つまり何らかの形で単一のモデルと対話できることが明らかになります。

;）

MVC / HMVCフレームワークを組み合わせた最適な構造を見つけました。メインには、ベースコントローラー/モデル/ビューを使用する必要があります...しかし、コースモジュールの個々のコンポーネントには...

したがって、MVC / HMVCフレームワークの構造は次のようになります。

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

また、モジュールライブラリ、i18nまたはヘルパーを追加する必要がある場合。

命名規則は簡単です。コントローラーとモデルの場合、接尾辞_Controllerと_Modelを追加します。モジュールのコントローラーとモデルの場合、exの場合はモジュール名のプレフィックスも追加します。モジュールUserのコントローラープロファイルは、User_Profile_Controllerという名前になります。

したがって、必要なものを見つけるのは非常に簡単かつ迅速です。

問題：長い名前（Forum_Model_Forum）

クラスの体系的な命名は、コンポーネント間の命名の競合を回避するのに役立ちます。クラスに長い名前を付けても、パフォーマンスが大幅に低下することはありません。どこから来るのかが簡単にわかるため、コーディングの際にこの命名スキームがかなり役立つと思います。

ファイルシステムの検索（どのフォルダーにフォーラムモデルがあるか）。

これはシステムの実装方法に大きく依存しますが、ファイルシステムの構造は通常、ファイルシステムを広範囲に検索することなく、正しいコンポーネントにすぐにアクセスできるようにします。

フォーラムコンポーネントを使用する場合の例を次に示します。

情報：

• コンポーネント名：フォーラム

• コントローラー名：インデックス

  $ controller_path = BASEDIR。'module /'。$ component_name。'/ controller /'。$ controller_name。'.php';

また、一般的なWebサイトの起動時に文字通り何百ものファイルシステムクエリがあるため、一部を追加しても問題はありません。

私は最初の「標準MVC」で始まったWebサイトで作業しましたが、最終的には「モジュラーMVC」になりました。

小規模なWebサイトを運営しており、あまり経験がない場合は、「標準MVC」から始めることをお勧めします。ウェブサイトが非常に複雑で大きくなることを既に知っている場合は、「モジュラーMVC」に慣れる必要があります。最初は少し難しくなりますが、最終的には、それ。

私は実際に自分でフレームワークに取り組んでおり、モジュールベースとフリーフォームの両方のディレクトリ構造の組み合わせを使用しています。フレームワークを使用したサイトコードのデフォルトの構造は次のとおりです。

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

また、コントローラーに関連しないモジュールフォルダーを持つこともできます。デフォルトでは、ヘッダーやフッターなどのサイト全体のテンプレートを保存するために使用されるCoreを呼び出します。これは私に両方の長所を提供します。フォルダーごとに1つのコントローラーがあるため、コントローラーの場所を簡単に知ることができますが、モデルのようなクラスの場合、1つのディレクトリの下にあるファイルの場所を検索する必要はありません（モデルの名前もきれいに保ちます） 。

ユーザーがクラスを配置できる場所に異なるディレクトリを設定できるようにするため、ファイルをロードする方法は少し異なります。そのため、最初にディレクトリを解析し、すべてのクラスファイルの場所をjsonファイルに保存してから、それを使用してすばやく検索します他のすべてのリクエスト（これを改善する方法を検討していますが）。

これに対する答えは、すべての大規模システムが適応し始めているか、現在採用されているPSR-0提案によって決定されています。

構造は次のとおりです。

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

これは、長いファイル名を修正するためにできることは何もないことを意味します。

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

これはまた、すべて小文字の代わりにダムの大文字小文字混在ファイルを使用する必要があることを意味します（サードパーティのライブラリが機能しない場合は動作しません）。

Mathiasesソリューションは非常に理にかなっています。また、彼のフォルダー構造を使用しても、プラグ可能なコンテンツを持つことを妨げません。たとえば、独立した/ gallery /を追加すると次のようになります。

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

これで、必要に応じて共有の「モデル」と独立したモデルができました。