Question

在Web MVC项目中，我具有以下结构：

mymvc/                      -> Project root.
    public/                 -> Document root. The only one folder accessible from web.
        assets              -> Client-side assets. NOT ONLY for global themes and libraries, BUT ALSO for each specific "view" controlled by the "src/Application" components.
            css/
            js/
            images/
            ...
        index.php           -> Application's entry point.
    src/                    -> UI layer rules.
        Application/
            Controller/
            View/
            ViewModel/
        Dispatcher/         -> Application dispatching - route matching, dispatching to the specified controller, etc.
        ...                 -> Other classes used by the components in the "src/Application" folder.
    templates/              -> Layout and template files.

注意：所有域模型组件（实体，存储库，数据映射器，服务等）都位于mymvc目录之外的文件夹中，以便其他任何应用程序也可以访问它们。

实际上，我想过要做以下两个步骤：

要将templates目录移动到src/Application文件夹中。
要将assets目录移动到src/Application，在Web服务器（Apache）配置中创建别名/assets/-指向已移动的文件夹，并允许从外部世界。

全局使用的资产（例如css主题或js库代码，背景图片等）仍可以保留在public目录中-显然不在命名或别名为assets的文件夹中

我发现这两个步骤确实是个好主意，因为如我所见，这两个文件夹都包含与src/Application中的结构相关的资源。因此，不要像这样：

src/Application/Controller/AboutUs.php
public/assets/js/AboutUs.js
templates/AboutUs/[multiple-layout-and-template-files]，

以下结构似乎更好：

src/Application/Controller/AboutUs.php
src/Application/assets/js/AboutUs.js
src/Application/templates/AboutUs/[multiple-layout-and-template-files]，

但是，在研究了许多Web框架之后，我意识到它们都使两个文件夹（templates和assets）与应用程序文件夹完全分开。

所以我想问：是否有任何特定原因，为什么我建议的两个目录的移动不能执行或不应该执行？

谢谢。

Answer 1

这一切都取决于您要实现什么以及您的工作流程是什么。您似乎正在使用PHP工作-值得研究像Ruby on Rails这样的非PHP框架。

通常，您希望输出文件夹为“只读”-开发人员不应手动编辑文件，而是构建和部署管道运行诸如Gradle之类的工具来转换SASS / LESS和JS文件（来自{{1 }}文件夹）放入CSS和最小化/串联的Javascript中，并将它们放置在/source中的正确位置。对于开发和生产构建，构建和部署管道通常具有不同的配置（例如，仅针对生产最小化）。

在Ruby on Rails中，该结构大体上如您所说的“好得多”-除了“ templates”是位于“ views”下方的名为“ layouts”的文件夹。有一个构建步骤（自动运行），可以转换各种资产文件（SASS / LESS，JS等）。

您可以看到Ruby on Rails目录结构here的详细描述。 here说明了Django的目录结构。

回答您的评论中的问题：

SASS / LESS / JS / Coffee脚本文件应该放在哪里？-由您决定。在Rails中，它们生活在/public和/app/assets/javascript中；在这些文件夹中，每个视图都有一个文件，以及应用程序级文件。这使您的构建过程变得轻松而简单-您只需要担心两个文件夹，并且不必在每次创建新视图时都修改构建。
如何构造视图-我具有应用程序级视图和特定的页面视图。同样-主要是为了方便起见。在Rails中，所有模板都位于/app/assets/stylesheets下。应用程序级视图位于一个名为/app/views的文件夹中-它们实际上与页面级模板没有什么不同，因此将它们移出该文件夹似乎并没有太大的作用，而将所有内容保持不变顶层文件夹使构建和配置更加简单。

因此，不，没有理由按照您的建议去做。

Answer 2

我认为每个人都可以使用最适合他/她的结构。

过去的几年中，我一直在与CodeIgniter一起工作，并且自己也在处理文件和文件夹。最后，我思考我有了喜欢的结构：）

对于应用程序文件夹I，大多数情况下，请按照其手册和教程中所建议的（基本）结构进行操作。

它看起来像这样：

- versionX
    - application
        - config
        - controllers
            - assets // Folder to keep asset specific controllers
                css.php
                js.php  // These controllers are bundling all resources and returning it as css, js or image file. Images can be cropped etc by params in url. Framework routes urls as domain.com/css/stylesheet.css to the css.php controller etc
                img.php
            documents.php // normal controller files
            users.php
            ...
        - core // core (controller) files from which controllers can extend
            APP_Controller.php
            APP_AssetController.php
            ...
        - helpers // Holds files with functions that you can use everywhere in the app.
        - libraries // Holds library files and folders
            PasswordHash.php
            Permissions.php
            Template.php
            Twitter.php
            ...
        - models // holds files with all DB logic (one file per DB table in my case, join tables not included)
    - public
        - css
        - js
            - components // javascript files for specific (large) page element(s)
                modal.js
                timeline.js
            - controllers // one js file per controller for controller specific js code
                documents.js
                users.js
            - resources // all libraries from 3rd party (Bootstrap, jQuery, ...)
        - uploads // user generated content (folder divided per file use/ origin)
    - themes
        - blueSky
            - views
                - layouts // app level views
                    - partials // app level partials (main navs, footers, ...)
                - documents // a folder per controller
                    - modals // modals used at document controller
                        _merge_document.php
                        _split_document.php
                    - partials
                        _form.php // for adding and editing documents
                        _drawer.php // submenu for document controller
                    index_view.php
                    create_view.php
                    edit_view.php
                    ...
                - users

我希望这会让您对我的操作有所了解。但是您确实应该做最喜欢的事情。没有比浏览不喜欢的东西更糟糕的了。

Answer 3

对代码进行分类

我唯一推荐的是保持名称空间等于目录结构，以使自动加载保持简单。从那里开始，语言并不关心代码的组织方式。两个限制是名称空间和目录：它们是分层的。这样就可以确定您只能按层次结构对代码进行分类。

实际的问题是分层分类本身就是一个问题。可以通过多种方式对对象进行分类。幸运的是，PHP对分类是不可知的，那么为什么人类不能一样？因为我们实际上在考虑代码和对象。我们搜寻，使用，培育它们。这只是个人经验和品味的问题，您与某些对象行为之间最牢固的关联是什么？

还有一件事要考虑：“地狱是其他人。”

一旦您的代码开始依赖于特定的框架，使分类与Symphony框架的分类保持兼容将很方便。或其他人的分类方案可能是您不愿遵守的。

无论哪种方式，没有理由不去做你想要的事情。如果以后再改变主意，至少您会自己知道为什么要改变主意，并会从中学习。

为什么没有MVC应用程序的紧凑结构？

3 个答案:

对代码进行分类