MVCフレームワークに関しては、2つの主なコードベース構造があります。問題は、どちらにも組織的なバグがあるように見えることです。
標準MVC
_/controller
/model
/view
_
問題:関連コンポーネント(フォーラム、ブログ、ユーザーなど)が分離されていません)
モジュラーMVC
_/blog
/controller
/model
/view
/user
/controller
/model
/view
/forum
/controller
/model
/view
_
モジュールベースのシステムを選択すると、問題が発生します。
is_file()
を使用してファイルシステムを検索し、フォーラムモデルが存在するフォルダを見つけますか? (小花のように)異なるモジュールを分離しようとするときにうまく機能する他のMVC構造はありますか?これらの構造から得られる利点はありますか?
これに対する答えは PSR-0 Proposal によって決まり、すべての大規模システムが適応し始めているか、現在採用されています。
構造は次のとおりです。
\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
これは、すべて小文字ではなく、大文字と小文字が混在したファイルを使用する必要があることも意味します(サードパーティのライブラリが機能しない場合)。
試してください:
/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を追加します。モジュールのコントローラーとモデルの場合は、例として、モジュール名のプレフィックスも追加します。モジュールUser内のコントローラープロファイルは、User_Profile_Controllerと命名されます。
したがって、必要なものを見つけるのは非常に簡単で高速です。
問題:長い名前(Forum_Model_Forum)
クラスの体系的な命名は、コンポーネント間の命名の競合を回避するのに役立ちます。クラスに長い名前を付けても、パフォーマンスが大幅に低下することはありません。どこから何が来るのかが簡単にわかるので、この命名体系はコーディング時にかなり役立ちます。
ファイルシステムの検索(どのフォルダにフォーラムモデルがありますか?).
これはシステムの実装方法に大きく依存しますが、ファイルシステムの構造は通常、大規模なファイルシステム検索を行わなくても正しいコンポーネントに即座にアクセスできる規則に従っています。
以下に例を示します。フォーラムコンポーネントを使用するとします。
情報:
コントローラー名:インデックス
$ controller_path = BASEDIR。 'モジュール/'。 $ component_name。 '/ controller /'。 $ controller_name。 '.php';
また、一般的なWebサイトの起動時には、文字通り何百ものファイルシステムクエリが存在するため、追加しても害はありません。
私は実際に自分でフレームワークに取り組んでおり、モジュールベースのディレクトリ構造と自由形式のディレクトリ構造の両方を組み合わせて使用しています。フレームワークを使用したサイトコードのデフォルトの構造は次のとおりです。
/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ファイルに格納し、それを使用してすばやく検索します。他のすべてのリクエスト(これを改善する方法を探していますが)。
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
これで「モデル」が共有され、必要に応じて独立したモデルができました
私は最初の「標準MVC」で始まったWebサイトを使用していますが、最終的には「モジュラーMVC」になります。
小規模なWebサイトを作成していて、経験が少ない場合は、「標準MVC」から開始することをお勧めします。 Webサイトが非常に複雑で大きくなることがすでにわかっている場合は、「モジュラーMVC」に慣れる必要があります。最初は少し難しくなりますが、最終的には次のことに慣れます。それ。