脚本语言 MVC 应用程序的最佳文件系统结构

发布于 2024-08-04 14:13:51 字数 1373 浏览 7 评论 0原文

当我谈到脚本语言时,我指的是 Python、Perl 和(就我而言)PHP 等语言。在使用 CodeIgniter、Zend 和许多其他有趣的 MVC 系统之后,很明显,人们似乎都同意的一件事是文件夹结构(以及其他类似的东西)。这确实给我带来了问题,因为我找不到任何关于不同结构设计的好处的好的文档。大多数人只是推荐一种,因为这就是他们使用的,而不考虑设计的改进。

我希望我们都同意的一件事是,在自动加载类时检查文件系统中的现有文件是非常糟糕的做法。我们的类不应该位于 5 个可能的位置之一,从而导致对我们加载的每个库进行大量的 file_exists() 检查。

因此,无论如何,我正在尝试收集目录结构,以便在规划以下应用程序时可以进行比较,以找到最佳实践:

  1. 基于 OOP,这很可能意味着 MVC
  2. 在范围内是国际化的,并且支持语言文件/翻译
  3. 对模块/插件开放,因此完整的包可以放入我们的代码库中
  4. 清楚地定义正在发生的事情以及在哪里查找给定的类
  5. 可能支持运行相同结构的多个站点(请参阅下面的 /site 目录)

所以这就是我到目前为止所拥有的。请记住,libs 只是一个术语,表示您的主库/类目录,甚至可能包含模型,具体取决于文件夹结构。另外,我排除了任何类型的静态内容(JS/CSS/图像),因为这些内容实际上是事后的想法,与我们的服务器端代码无关 - 它甚至可能位于另一台服务器上!缓存、文件上传、语言和所有其他生成的内容也是如此。

/controllers
/views
/models
/libs
/config
index.php

这让我想起了 Zend 框架,它将所有内容都堆放在一个 libs 文件夹中(其中还包括子文件夹以保持组织有序)。仅适用于单个站点。


/libs
/site
    /controllers
    /views
    /models
    /config
index.php

这将是上述结构的多站点版本。


/libs
/functions
/site
    /controllers
    /models
    /views
    /config
/site2
    /controllers
    /models
    /views
    /config
/modules
    /user
        /controllers
        /models
        /views
index.php

这将是允许多个站点放入模块的版本。这些模块将是独立的 MVC 应用程序,例如论坛,其中包括业务逻辑、CRUD 和视图。

那么有没有人有一个完美的结构可以分享或指导我选择一个好的可扩展设计?

When I speak of scripting languages I am speaking of languages like Python, Perl, and (in my case) PHP. After using CodeIgniter, Zend, and lots of other fun MVC systems it seems clear that one thing one one seems to agree on is the folder structure (alongWithOTher things_like_that). This is really causing a problem for me because I can't find any good documentation on the benefits of different structure designs. Most people just recommend one because that is what they use without regard for improvements in design.

One of the things I hope we can all agree on is that checking the file system for existing files when autoloading classes is very bad practice. Our classes should not be in one of 5 possible locations causing a barrage of file_exists() checks for each library we load.

So anyway, I am trying to collect directory structures that I can compare to find the best practices when planning for applications that:

  1. Are OOP based which most likely means MVC
  2. Are International in scope and support language files/translations
  3. Are open to modules/plugins so that complete packages can be dropped into our codebase
  4. Clearly define what is going on and where to look for given classes
  5. Possible support for multiple sites running off the same structure (see /site directories below)

So here is what I have so far. Keep in mind that libs is just a term meaning your main library/class directory and may even contain models depending on the folder structure. Also, I excluded any type of static content (JS/CSS/images) as that stuff is really an after thought and not related to our serverside code - it may even be on another server! The same thing with caches, file uploads, lang, and all other generated content.

/controllers
/views
/models
/libs
/config
index.php

This kind of reminds me of the Zend framework which piles everything into a single libs folder (which also includes subfolders to keep things organized). Only works for a single site.


/libs
/site
    /controllers
    /views
    /models
    /config
index.php

This would a multi-site version of the above structure.


/libs
/functions
/site
    /controllers
    /models
    /views
    /config
/site2
    /controllers
    /models
    /views
    /config
/modules
    /user
        /controllers
        /models
        /views
index.php

This would be version that would allow multiple sites and drop in modules. The modules would be self contained MVC apps like a forum which would include business logic, CRUD, and views.

So does anyone have a perfect structure they could share or guide me in choosing a good extend-able design?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

太傻旳人生 2024-08-11 14:13:51

这是一个过于复杂的示例,它很好地组织了所有内容 - 但代价是清晰度和简单性。

替代文本
(来源: gsdesign.ro)

Here is an overly complex example that does a good job of organizing everything - at the cost of clarity and simplicity.

alt text
(source: gsdesign.ro)

音栖息无 2024-08-11 14:13:51

不是特别推荐symfony,而是它的方法,我认为是相当好(但不是“完美”)

允许:

  • I18N
  • 多个环境(dev、qa、prod 等)
  • 外部库
  • 插件
  • 多个站点(域或其他)
  • 批处理(命令行任务)
  • 单元测试
  • 文档 日志
  • 记录
  • 缓存

另外,在 symfony 的起起落落中,我认为它做得很好的一件事正在缓存。我的意思不是 模板/视图缓存 - 我的意思是 < a href="http://www.symfony-project.org/book/1_2/05-Configuring-Symfony#chapter_05_the_configuration_cache" rel="nofollow noreferrer">类似编译的缓存。

当项目第一次执行时,symfony 会构建一个库类的主文件,该文件在连续命中应用程序后,不仅会删除每个请求的数十甚至数百个 stat 调用,还会执行其他优化,例如删除注释。

它还缓存配置数据和自动加载信息,所有这些都可以根据您的需求进行调整。

Not to specifically recommend symfony, but rather it's approach, which I think is pretty good (but not "perfect")

Allows for:

  • I18N
  • Multiple environments (dev, qa, prod, etc)
  • External libraries
  • Plugins
  • Multiple sites (domains or otherwise)
  • Batch processing (command-line tasks)
  • Unit tests
  • Documentation
  • Logging
  • Caching

Also, among symfony's ups and downs, one thing I think it does pretty well is caching. And I don't mean template/view caching - I mean compilation-like caching.

When a project is executed the first time, symfony builds a master file of library classes which, upon successive hits to the application, not only removes dozens or even hundreds of stat calls per request, but performs other optimizations like the removal of comments.

It also caches configuration data and autoload information, all of which can be tweaked to suit your needs.

黎夕旧梦 2024-08-11 14:13:51

我们使用类似于您最后一个“多站点”选项的结构来构建我们内部构建的多站点论坛引擎,并且效果非常好。如果需要,您始终可以复制模块,并且它还允许站点 A 稍微定制其模块而不影响站点 B。

当您进入实际应用时,您正在谈论完全独立的团队,甚至可能使用这两个网站的企业,一点点分裂并不是最糟糕的事情。我们还有一个共享模块文件夹,但如果您在站点的模块文件夹中将文件命名为相同的名称,它将使用该版本。使用它和 __autoload (假设是 PHP),站点开发人员实际上不必担心模块位于何处即可使用它。

We use a structure similar to your last "multi-site" option for a mutli-site forum engine we built in house and it works out really well. You can always copy modules over if you need, and it also allows for the possibility of Site A customizing their module a little without affecting Site B.

When you get into practical applications of this, you're talking about completely separate teams, maybe even businesses using those two sites, a little division is not the worst thing. We also have a shared modules folder, but if you name a file the same thing in the Site's modules folder, it uses that version instead. Using that and __autoload (assuming PHP), then the Site devs don't really have to worry about where the module is located to use it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文