Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/php/277.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Php Laravel:有没有办法转换为依赖注入_Php_Laravel - Fatal编程技术网

Php Laravel:有没有办法转换为依赖注入

Php Laravel:有没有办法转换为依赖注入,php,laravel,Php,Laravel,我正在构建一个搜索功能 速度优先于从查询中获取结果,因此,我使用本机SQL 结果取决于用户/组权限、关键字和搜索选项(名称、说明、全部等) 该选项是可扩展的,因此,使用依赖项注入可能是最好的,但我就是不知道如何在这个需求中使用它 我知道“如果”这句话很管用。然而,我试图遵循“单一责任原则”,并给出下面的代码 它目前工作正常,但看起来不太对劲。有没有办法将其转换为依赖项注入?也许你可以帮我解释一下为什么下面的代码已经很好了,或者只是不好,然后给我一个解决方案 接口: interface Searc

我正在构建一个搜索功能

速度优先于从查询中获取结果,因此,我使用本机SQL

结果取决于用户/组权限、关键字和搜索选项(名称、说明、全部等)

该选项是可扩展的,因此,使用依赖项注入可能是最好的,但我就是不知道如何在这个需求中使用它

我知道“如果”这句话很管用。然而,我试图遵循“单一责任原则”,并给出下面的代码

它目前工作正常,但看起来不太对劲。有没有办法将其转换为依赖项注入?也许你可以帮我解释一下为什么下面的代码已经很好了,或者只是不好,然后给我一个解决方案

接口:

interface SearchQueryInterface
{
    public function searchQuery($user_id,$user_group, $keyword);      
}
// search by All
class SearchAll implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}

// search by Name
class SearchName implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}

// search by Description
class SearchDescription implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}
实现接口的类:

interface SearchQueryInterface
{
    public function searchQuery($user_id,$user_group, $keyword);      
}
// search by All
class SearchAll implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}

// search by Name
class SearchName implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}

// search by Description
class SearchDescription implements SearchQueryInterface{

    public function searchQuery($user_id,$user_group, $keyword)
    {
        // results = Select query based on $user_id, $user_group and $keyword
        // return query results;
    }
}
控制器:

class SearchController extends \BaseController {   

    public function postSearch()
    {
        $user_id = 2;
        $user_group = 1;

        $option = Input::get('search_option');
        $keyword = '%'. Input::get('search_keyword') .'%';

        // get the class based on option
        $search_query = App::make('Search'. $option );
        $results = $search_query->searchQuery($user_id,$user_group, $keyword);

        var_dump($results);
    }
}

你的问题很有趣。在第一句话中,你说“我正在构建一个搜索功能”,然后你提出了很多与对象相关的代码,而不是函数

事实上,你问的是哲学,而不是事实。所以我想,在这个论坛上没有人能给你一个明确的过程或方法。所以你碰到了几个问题,一组专家可以讨论多年。让我为其中一些努力:

  • 我是否需要Web应用程序中的对象?说“是”的人认为代码清晰,oop是常识模式(因为他们的思维方式是对象)。不说废话的人将向您指出http协议的本质,它强烈地(事实上只是)支持导入过程输出模式(这可以通过oop解决,但oop不会比函数编程增加价值)

  • 您需要在哪里应用MVC模式?MVC的专业人士将此视为贯穿一生的哲学,他们甚至连一杯咖啡都喝不出来,却无法说出流程和所有获得的资产是如何融入MVC的。然后有人倾向于将MVC的范围扩展到任何方向,这两个人显然会对MVC有不同的定义。第三组人将能够成功地质疑MVC的各个方面

  • 如何将对象映射到数据库?这本身就是一个很好的反模式。关系数据库的一个主要优点是,与同一主键相关的所有外键也彼此相关。对象到对象只存储指针。从一个包含对象的指针到另一个指针的结束数据需要有更多的指针。所有这些都必须得到维护。在这一点上,objectheros发明了各种各样的消耗性能的技巧,比如object-to-db映射,很显然,幸运的是,给定的示例代码片段确实拒绝使用这些技巧

  • 嗯,我想我可以对extends和“class”-关键字以及php中的对象表示法、名称空间和依赖注入等做更多的介绍。然而,我担心,我已经开始在我的话中加入一些挫折的概念。让我们不要悲伤,让我们停在这里


    我唯一的建议是:如果要构建搜索函数,只需这样做并删除所有开销,这会使函数成为一个对象。

    我猜是因为这句话:$keyword='%'。输入::get('search_关键字')。';您的sql不是准备好的语句,并且是sql可注入的。也许我错了,但要小心。谈到您的代码,我认为您可以使用一个单一的接口来简化它,该接口用于所有查询和基于组的不同实现或您想要的内容,如SearchQueryAdmins、SearchQueryGuests等等…@CarlosGoce,感谢您的警告。我这样做是为了防止sql注入。我基于选项进行分离的方式是因为可扩展选项是选项。它将始终基于用户、组和关键字。我之前把选项放在“if”语句中。但是在看了laracast和Taylor Otwell关于单一责任、依赖倒置等的书之后,我认为稍后进行单元测试可能会更好。但是,现在我把自己和依赖注入混淆了。谢谢你的解释。很抱歉让您对“搜索功能”感到困惑。我试图告诉大家,它最初只有一个函数,它位于名为“postSearch”的控制器“SearchController”方法中。查询和所有内容都在“if”语句中处理。在阅读了Taylor Otwell的书籍并观看了Laracast之后,我尝试根据所讲述的内容(单一责任、依赖倒置等)构建函数。我不知道如何将代码转换为依赖项注入我在所有搜索方法中的注释也可能会让人困惑,所以我对其进行了少量编辑。是的,我知道这个问题会有很多争论。所以你是说最好还是回到“if”语句?这至少会让你的代码更可读。。。实际做你自信的事情。如前所述,对于web应用程序,oop在好处方面胜过函数式编程的用例非常罕见。因此,如果您需要在将函数式编程转换为面向对象编程方面投入大量额外的精力,那么您可能会浪费大量的时间。另一方面,如果你总是做oop,你可能会在这方面的实践更有效率。在这种情况下,我不会建议您切换到函数式编程。有一个很好的额外方面。你说过“速度优先”。当您的数据存储在数据库中时,您在速度方面的主要收获就是在这方面进行优化。因此,如果您有2天的时间,您可以自由决定是否使用它将功能代码转换为oop代码,并使该模式稳定,还是将其用于数据库优化,我显然会投票支持数据库优化。我喜欢您的额外方面。嗯,我做了数据库优化,我可以立即得到成千上万的结果。我只是有点空闲时间