【问题标题】:Laravel 5.1 > use @inject within view to display contentLaravel 5.1 > 在视图中使用 @inject 来显示内容
【发布时间】:2015-09-06 15:44:27
【问题描述】:

我正在开发一个小型 Web 应用程序,该应用程序将具有一个私人消息传递系统。当用户登录时,他收到或写入的消息将显示在下拉菜单内的工具栏区域中。没什么新鲜的:-)

当用户浏览页面时,大部分时间都会显示工具栏。因此,我没有将收件箱实现注入可能通过 routes.php 调用的每个控制器,而是考虑使用新的刀片函数 @inject。

这看起来像这样(抽象)

  1. 工具栏视图通过@inject 调用ControllerMethod
  2. ControllerMethod 调用注入的 InterfaceMethod(基于构造函数的注入)
  3. 服务容器服务于实现
  4. ImplementationMethod 返回收件箱

但我不确定这是否是一个不错的设计模式,因为我对依赖注入一般来说相对较新。我会很感激一些想法。

【问题讨论】:

    标签: php laravel-5 inject


    【解决方案1】:

    这里有两件事对我来说是错误的。

    1) Laravel 的 @Inject 视图指令实际上并没有做任何类型的“依赖注入”,尽管它的名字暗示了这一点。它实际上是使用服务位置,一种被广泛认为是反模式的模式。

    基本上,通过@Inject,视图可以访问容器中的任何内容。它可以得到任何想要的东西。它没有被告知它应该有什么。这就是依赖注入和服务定位的主要区别。

    2) 直接将服务注入视图无疑意味着您将增加应用程序的复杂性,因为您添加了更多可以将服务 注入模板的位置。虽然从短期来看,它可能会使事情变得更快、更简单,但从长期来看,它会让事情变得更难处理。

    3) 如果在您的视图中发生这种情况,您将如何测试获取和控制数据的方式?您可能不得不使用功能测试,虽然这不是一件坏事,但仍然不会像单元测试那样有用。

    我建议坚持关于 DI 的通常做法,并实际使用 DI。

    【讨论】:

    • 就像我描述的那样,DI 发生在控制器的第二步(基于构造函数的注入)中,而不是直接使用 @inject。它也通过合同松散耦合。所以测试应该不是问题。主要是我不知道哪种设计模式可能是实现我所描述的那种设计模式的好选择:让一个类将用户收件箱输出到每个请求,而无需将其注入每个控制器。
    猜你喜欢
    • 2014-04-27
    • 1970-01-01
    • 1970-01-01
    • 2016-07-18
    • 2016-08-11
    • 2016-11-21
    • 2015-02-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多