2

我正在阅读 Taylor Otwell 的书，他建议使用存储库模式。我明白它背后的理论。切换实现和解耦代码很容易。我也得到了代码。能够App::bind()与其他一些实现进行切换是非常好的。但在过去的两个小时里，我一直在思考我应该如何处理我正在构建的新 CRM。几乎还没有代码，但最终可能会很大。

我宁愿简单地使用通过控制器注入的雄辩模型和集合。如果我没记错的话，那应该让一切都可以测试...... 允许模拟等。

存储库模式是否可能为可扩展性提供任何好处？在需要更多服务器或资源的情况下..

为什么有人想要替换曾经承诺使用的 Eloquent ORM？我的意思是大多数项目都需要一个关系数据库。如果我要构建一个UserRepositoryInterface和一个实现DbUserReponsitory，我看不到我什么时候需要或想要用其他东西来切换它。这适用于我项目中的大多数实体（订单、公司、产品……）。也许用另一个 ORM 来代替 Eloquent？但我不认为自己会为这个项目做这件事。

还是我错过了什么？我主要关心的是拥有可读且易于测试的代码。到目前为止还没有真正测试得那么好:)

4

2 回答 2

1

这并不一定意味着从长远来看忽略存储库模式会让您头疼，但它确实使重构代码变得更加容易，因此您可以轻松编写测试存储库并将它们与控制器绑定以轻松测试您的业务逻辑。

因此，即使您不太可能替换 Eloquent 或任何其他部分，在存储库中封装逻辑和操作块仍然对您有益。

于 2013-10-21T16:08:04.787 回答
1

依赖注入在设计模式方面并不是什么新鲜事，它是否会伤害你的代码，不一定。是否会损害您轻松编写/重构旧代码并轻松交换它的能力......绝对会。

设计模式作为常见问题的解决方案而存在。我会马上告诉你，如果你正在编写复杂的应用程序，那么忽略 Laravel 中的 IoC 容器而不是依赖注入将会对你产生很大的影响。例如，您可能需要基于请求类型、用户角色/组或任何其他因素组合的不同绑定，通过在不影响调用代码的情况下交换类对您来说将是无价之宝。

我的建议是，根本不要忽略 IoC 容器。

作为旁注，服务提供商也是你的朋友，如果你想在 Laravel 4 中编写出色的应用程序，我建议你熟悉他们。

于 2013-10-21T16:02:13.653 回答