README

#LeagueFw

这个小框架主要关注尽可能使用 ThePHPLeague 组件。根据需要，它添加了一些兼容性或可用性层。整个框架适用于小型到中型应用程序。尽可能使用正确的类型提示，框架也试图对几乎所有内容都进行明确说明。

框架的目的是仅使用自动依赖关系解析，而不直接将容器注入到服务中。这不是一个硬性限制，但框架的桥接组件将考虑到这一点。

LeaugeFw 的每个兼容性层都将有一个接口。如果可能，将使用 PSR 接口。因此，应该很容易将其与几乎任何现有的框架兼容。

DI 容器也可以在引导过程中重新配置。实际上，提供的引导并不是真正必需的。它只是简化了使用，因为它只是初始化了 ThePHPLeauge 的一些核心组件。

需求

除了 composer 之外的唯一要求是 PHP7，因为我不会回顾旧的东西。它可能在 5.5+ 上运行，我想。也许我很快会设置一些测试并检查这一点...

结构

没有惯例，一切都必须配置为可用。然而，有一些推荐

app/ 包含整个应用程序代码。
examples/ 展示了一个可能的目录设置。
lib/ 将后来移动到自己的 Composer 包。
public/ 是应用程序的面向部分，并且只应该从网络访问这一点。
var/ 存储所有生成的缓存数据和/或动态配置数据，如 yml 或 ini 配置。

使用此结构的优点是它几乎立即与一些第三方工具兼容。

app/Resources/ 和 public/ 结构使得 laravel-elixir 的配置和使用变得简单。

一些现代 PHP 应用程序也将它们的配置和缓存存储在 var/ 文件夹中，因此更容易在应用程序文件夹中查找这些数据。

为什么还需要另一个框架，而不是？

这并不是关于“哇，我创建了一个，在我看来超级简单、超级快或超级可配置的微框架!!!!!!11!1 让我们进行微基准测试！1!11”的事情。这是关于“无框架”的方法，如在这个存储库中所述。Composer 使得这变得相对容易，我认为为什么不尽可能多地使用一个命名空间中的组件呢？

所以我只是想拼凑一些东西来熟悉所有流程，也许会在一些小型私有项目中使用它。我也觉得有些框架对我来说很糟糕，因为你需要一些 'idehelper.php' 来在你的 favorite IDE 中获得适当的提示。其他一些问题在于它们对我来说过于“全局”，我不是laravel引入的 facade 事物的粉丝。

我喜欢真正的 Container DI，具有自动装配，但必须先明确配置。请不要涉及魔法！因为我们都知道，魔法必须被缓存，魔法有时会失控。

blackskyliner / leaugefw

维护者

详细信息

README

需求

结构

为什么还需要另一个框架，而不是？