没有紧凑结构的 MVC 应用程序的原因是什么？

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 目录中——显然不在名为 or 的文件夹中别名 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],

但是，在我研究了很多网络框架之后，我发现它们都将两个文件夹（templates和assets）与应用程序文件夹完全分开。

所以我想问一下：有什么具体的原因，为什么我提出的两个目录的移动不能，或者不应该做？

谢谢。

Answer 1

这完全取决于您想要实现的目标以及您的工作流程。您似乎在 PHP 工作 - 值得研究非 PHP 框架，例如 Rails.

上的 Ruby

通常，您希望输出文件夹为 "read-only" - 开发人员不应手动编辑文件，而应使用 Gradle 等构建和部署管道运行工具将 SASS/LESS 和 JS 文件（来自 /source 文件夹）到 CSS 和 minified/concatenated Javascript 并将它们放在 /public 中的正确位置。构建和部署管道通常对开发和生产构建具有不同的配置（例如，仅针对生产进行缩小）。

在 Rails 上的 Ruby 中，结构大部分与您描述的 "much better" 相同 - 除了 "templates" 是 "views" 下的一个文件夹，名为 "layouts"。有一个构建步骤（运行s 自动转换各种资产文件（SASS/LESS、JS 等）。

在Rails目录结构here. Django's directory structure is explained here.

上可以看到Ruby的详细说明

回答您评论中的问题：

SASS/LESS/JS/Coffee 脚本文件应该放在哪里？ - 由您决定。在Rails，他们住在/app/assets/javascript和/app/assets/stylesheets；在这些文件夹中，每个视图都有一个文件，还有应用程序级文件。这使您的构建过程变得简单明了 - 您只需担心 2 个文件夹，并且不必在每次创建新视图时都修改您的构建。
我如何构建我的视图 - 我有应用程序级视图和特定页面视图。 同样 - 主要是一个方便的问题。在 Rails 中，所有模板都位于 /app/views 下。应用程序级视图位于名为 /app/views/layouts 的文件夹中 - 它们实际上与页面级模板没有太大区别，因此将它们移出该文件夹似乎并没有取得多大成就，而将所有内容保持在同一文件夹中顶级文件夹使构建和配置更简单。

所以，不，没有理由按照你的建议去做。

Answer 2

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

在过去的几年里，我一直在使用 CodeIgniter，并且自己也在处理文件和文件夹。最后我认为我有我喜欢的结构:)

对于应用程序文件夹，我主要坚持使用他们的手册和教程中推荐的（基本）结构。

看起来像这样：

- 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 对分类是不可知的，那么为什么人类不能一样呢？因为我们实际上考虑的是代码和对象。我们寻找它们，使用它们，培养它们。这只是个人经验和品味的问题，您与某些对象行为的最强关联是什么？

还有一件事需要考虑："Hell is other people."

让您的分类与其他分类兼容，例如 Symphony 框架的分类，一旦您的代码开始依赖于该特定框架，就会派上用场。或者别人的分类方案可能是你不愿意受的。

无论如何，没有理由不做你想做的事。如果以后你改变了主意，至少你自己会知道为什么改变了，你会从中吸取教训。

没有紧凑结构的 MVC 应用程序的原因是什么？

Reasons for not having a compact structure of an MVC application?

php

architecture

model-view-controller

web-applications

directory-structure

对代码进行分类