Laravel 文件夹结构

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/21379434/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-14 08:55:22  来源:igfitidea点击:

Laravel folder structures

phparchitecturelaravellaravel-4directory

提问by AndrewMcLagan

Often i come find it problematic when deciding where to place folders to resources within the app\folder.

在决定将文件夹放置到文件夹中的资源的位置时,我经常发现它有问题app\

Where should i place things such as model observersand validatorsand form macrosand repositories.... currently i do the following

我应该在哪里放置诸如model observersandvalidatorsform macrosand repositories.... 目前我执行以下操作

\app
   \models
   \controllers
   \repositories
   \observers
   \interfaces
   \validators 
   \views

although i see some people do the following:

虽然我看到有些人做以下事情:

\app
   \models
   \controllers
   \views
   \YourAppNameHere
      \Services
         \validators
         \...

I do not understand the reason behind the \Acme folder when its the same as the actual application?

当 \Acme 文件夹与实际应用程序相同时,我不明白其背后的原因?

回答by Miroslav Trninic

Best way to master Laravel folder structure is to treat appdirectory as a front end of framework. If you take a look at the git repositoryyou'll see that they are separated - you can clone core library and you can clone laravel application alone. Application, with it's subfolders represents just one way in which framework can be used. Ofcourse, it is designed with best practices involved. Check out also core framework testsdirectory - there Laravel developers treated library as "headless" - without application. For me, it was everything I need to grasp Laravel.

掌握 Laravel 文件夹结构的最佳方法是将app目录视为框架的前端。如果您查看git 存储库,您会发现它们是分开的 - 您可以克隆核心库,也可以单独克隆 laravel 应用程序。应用程序及其子文件夹仅代表可以使用框架的一种方式。当然,它的设计涉及最佳实践。还要查看核心框架测试目录 - Laravel 开发人员将库视为“无头” - 没有应用程序。对我来说,这就是我掌握 Laravel 所需的一切。

So you are free to modify existing structure, but keep in mind that some changes require you to composer dump-autoload- mostly because of namespaces.

因此,您可以自由修改现有结构,但请记住,某些更改需要您编写 dump-autoload- 主要是因为名称空间。

回答by mikedugan

By and large, Laravel can be structured in whatever way works best for you. Some people prefer the default architecture while other like domain-based architecture.

总的来说,Laravel 可以以最适合您的方式构建。有些人喜欢默认架构,而另一些人喜欢基于域的架构。

Both of my current projects deviate from this, using something like:

我目前的两个项目都偏离了这一点,使用的是:

/app
  /database
  /controllers
  /bin
  /views
  /config
  /storage

I keep a lot of my custom functionality in a service provider, although I have some generic helpers in the bin/along with my routes and filters.

我在服务提供者中保留了很多自定义功能,尽管bin/我的路由和过滤器中有一些通用帮助程序。

You can do whatever you want, just make sure you accordingly update your composer.jsonand app/start/global.phpto make sure the proper classes are autoloaded. And make sure you namespace everything correctly!

您可以做任何您想做的事情,只需确保相应地更新您的composer.jsonapp/start/global.php确保自动加载正确的类。并确保您正确命名所有内容!

Below is an example of the relevant sections of my composer.json and global.php just for an idea:

下面是我的 composer.json 和 global.php 的相关部分的示例,仅供参考:

composer.json:

composer.json

"autoload": {
    "classmap": [
        "app/commands",
        "app/controllers",
        "app/database/models",
        "app/database/migrations",
        "app/database/seeds"
    ]
},

app/start/global.php:

app/start/global.php

ClassLoader::addDirectories(array(

app_path().'/commands',
app_path().'/controllers',
app_path().'/bin',
    app_path().'/database/models',
    app_path().'/database/seeds',

));
require app_path().'/bin/filters.php';
require app_path().'/bin/helpers.php';
require app_path().'/bin/events.php';

回答by Eddy Ferreira

in short, it's completely a matter of preference and how you and your team see it best for readability, That being said it's good to have consistency across all your projects.

简而言之,这完全是一个偏好问题,以及您和您的团队如何看待它的最佳可读性,也就是说,在您的所有项目中保持一致性是很好的。