这被认为是滥用作曲家吗？

应用程序/，静态资源和类映射项目代码
SRC /，配置成加载命名空间PHP代码
供应商/的组合，包装用composer.json管理无论我发生什么框架内使用

，这将是正确的利用src目录意图是该项目的可用外移植的代码，或者是THA t vendor目录的作用是什么？

对于要共享的代码使用src目录可能会产生任何问题吗？

2014-03-12 Alexander Trauzzi

这似乎是一个合理的设计方法。 Composer允许您将自己的类自动加载到目录中，然后在composer.json中引用它。看到这个问题如何：Using Composer's Autoload

但是，这不会处理您的代码在src /下的版本控制。如果你要单独发布此，一旦你到一个Git回购检查它的地方，它可能是值得学习how to make your library installable through Composer和，像这样引用它：

"require": { 
    "me/testlib": "1.0.*" 
} 
"repositories": [ 
    { 
     "type": "vcs", 
     "url": "https://github.com/username/hello-world" 
    } 
]

当然，那么您会发现maintanining多源树，一个用于你的项目，另一个用于每个图书馆，但这是件好事？（“关注点分离”）。

来源

2014-03-12 07:58:50

因此，尽管目录结构本身很好，但您不会建议将代码置于'vendors'以外的地方吗？ –

'供应商/'是作曲家安装的东西。不要把你自己的东西放在那里，除非你根据我的建议通过作曲家从回购中获得它。我不确定我是否理解你的问题，但我认为一个恰当的答案是“我建议不要将自己的库与你的程序放在同一个源代码树中”。 –

是的，我的意思是“将代码放在供应商中”将是“编写一个包”的代名词。而且你建议'src /'目录仍然是项目级别，并且是整个解决方案的特定对象：开发人员不打算手动复制项目之间的整个目录以重用代码，而是应该为'供应商/'？ –

在一般情况下，您的方法看起来像是有效的方法。

但是，如果数据量为app或其他任何地方超过src中可用代码的数量，它将会失效。换句话说：如果你只在src中主持一个共享类，并且app中有一个千兆字节的资源不需要该类，那么将其作为一个库是愚蠢的。

但是在这种情况下，只需简单地将该类自己移入作曲程序库并再次包含它即可。由于自动加载，类仍然存在（尽管该文件改变了它的位置）并且可用于其他代码。任何其他需要大量资产的软件，即使该课程被移动，也将继续工作。

将代码移入库中时，可能值得考虑的是通常较小通常较好，但太小则毫无价值。你不希望require它自己的每一个类 - 但一个合理的集合类具有相同的主题，是一个很好的候选人。

来源

2014-03-12 20:46:36 Sven

而src /目录显然不是正确的放置代码的地方，可以跨页使用，对吗？ –

你可以把代码放在任何你喜欢的地方，实际上'src'是许多库的常用选择，连同它旁边的'tests'。我不明白为什么这应该是坏 - 我自己使用它。 – Sven

这似乎是作为作曲家指定供应商/作为管理外部依赖关系的目录的滥用。任何其他目录应该是项目特定的。 –

这被认为是滥用作曲家吗？

回答

相关问题