我正在读Taylor Otwell的书，他建议使用存储库模式。我理解它背后的理论。切换实现和解耦代码很容易。我也得到了代码。能够通过App::bind()切换到其他实现是非常好的。但在过去的两个小时里，我一直在思考如何处理我正在构建的新CRM。几乎没有代码，但它可能最终会很大。
我更愿意只使用通过控制器注入的雄辩模型和集合。如果我没弄错的话，这应该可以使一切都可以测试。允许嘲笑等。
存储库模式是否可以为可伸缩性带来任何好处？在需要更多服务器或资源的情况下..
为什么有人想要在使用后取代Eloquent ORM？我的意思是大多数项目需要一个关系数据库。如果我要构建一个UserRepositoryInterface和一个实现DbUserReponsitory，我无法看到我何时需要或想要用其他东西切换它。这将占我项目中的大多数实体（订单，公司，产品......）。也许用另一个ORM代替Eloquent？但我不认为自己为这个项目这样做。
或者我错过了什么？我主要担心的是具有可读且易于测试的代码。到目前为止还没有真正进行过那么好的测试：）
答案 0 :(得分：1)
依赖注入在设计模式方面并不新鲜，它会不会损害您的代码。
是否会影响您轻松编写/重新考虑旧代码并轻松交换旧代码的能力。设计模式作为常见问题的解决方案而存在。我会马上告诉你，如果你正在编写复杂的应用程序，忽略Laravel中的IoC容器而不是依赖注入会对你产生重大影响。例如，您可能需要基于请求类型，用户角色/组或任何其他因素组合的不同绑定，通过交换类而不影响您的调用代码对您来说将是无法估量的。
我的建议，根本不要忽略IoC容器。
作为旁注，服务提供商也是您的朋友，如果您想在Laravel 4中编写出色的应用程序，我建议您熟悉它们。
答案 1 :(得分：1)
这并不一定意味着从长远来看忽略Repository模式会让您头疼，但它肯定会使代码重新分解更容易，因此您可以轻松编写Test存储库并将其与控制器绑定以轻松测试您的业务逻辑。
因此，即使您不太可能替换Eloquent或任何其他部分，在存储库中封装逻辑和操作块仍然对您有益。