在支持模块/插件时如何组织MVC框架？[关闭]

关于MVC框架，我已经看到了两个主要的代码库结构。问题在于它们似乎都伴随有组织缺陷。

标准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
    ....

模型是应用程序的核心。您应该将它们设计并编码为独立的程序包。控制器只是模型的客户，碰巧将用户活动转化为模型的动作。视图只是显示模型数据的一种特殊方式。如果您的应用程序增长，则可以进一步将客户端与模型分离：

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_Profile_Controller。

因此，找到所需的东西非常简单快捷。

问题：长名称（Forum_Model_Forum）

类的系统命名有助于避免组件之间的命名冲突。长时间命名班级不太可能会施加严重的性能损失。我发现这种命名方案在编码时很有用，因为很容易看出来的是什么。

文件系统搜索（哪个文件夹具有论坛模型？）。

这在很大程度上取决于系统的实现方式，但是文件系统的结构通常遵循一种约定，该约定允许立即访问正确的组件而无需进行大量文件系统搜索。

这是一个示例，假设要使用论坛组件：

信息：

• 组件名称：论坛

• 控制器名称：索引

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

同样重要的是要注意，引导一个典型的网站时实际上有数百个文件系统查询，因此添加一些查询不会受到影响。

我与以第一个“标准MVC”开始但最终成为“模块化MVC”的网站合作。

如果您正在做一个小型网站，并且没有太多经验，则可能要从“ Standard 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的文件夹，用于存储站点范围的模板，如页眉和页脚。这对我来说是两全其美的。您可以轻松知道控制器的位置，因为每个文件夹只有一个控制器，但是对于像模型这样的类，您无需搜索文件在一个目录下的位置（这也使模型的名称更整洁） 。

加载文件的方式略有不同，因为我允许用户在可以放置类的地方配置不同的目录，因此我首先解析目录并将所有类文件位置存储在json文件中，然后使用该文件进行快速查找其他所有要求（即使我正在寻找改善方法）。

PSR-0提案决定了这一答案，所有大型系统都已开始采用或已采用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

现在我们有一个共享的“模型”，并在必要时使用独立的模型