【问题标题】:Should my service layer be stateless?我的服务层应该是无状态的吗?
【发布时间】:2012-01-04 00:45:28
【问题描述】:

我有一个服务层,它处理例如我的控制器和我的域模型(即:存储库、实体等)之间的关系。

在我的服务中,我有“获取”实体的方法,例如 getArticles,但我需要返回数组结果或对象集合。

所以我在我的方法 getArticles($array = false); 中添加了一个参数(实际上我的服务没有强制转换任何对象,它是由存储库完成的,但我需要为我的 API 提供该选项)

我的服务越来越大,我想知道在我的方法参数中定义它是否是个好主意,我认为这是因为我认为我的服务应该是无状态的,但我想知道它是否会最好在我的服务中有一个方法,该方法基本上执行 setUseArray($flag) 并在我的服务代理到我的存储库时向它提供该标志。

同样的想法,如果我使用我的服务返回分页结果,我应该在我的每个方法中设置页面和项目计数,还是应该在我的服务中使用全局方法来做到这一点?

有什么意见吗?

【问题讨论】:

    标签: architecture repository service-layer


    【解决方案1】:

    像往常一样,这取决于。大多数情况下,这取决于服务对象是否会同时使用。一般来说,使用参数传递所有内容似乎更灵活。将方法参数包装到 request 实体中可以避免客户端与方法签名的紧密耦合:

    class request { 
        bool getArrayInsteadOfCollection;
        int pageNumber;
        int itemsPerPage;
    }        
    

    我假设,您有一个 Web 应用程序,并且服务对象仅存在于请求上下文中。在这种情况下,您可以安全地选择以服务对象方式制作“重复”参数。看起来也不错——

    getArticles(filterParam) {
        //combine function and service-object-level parameters.
        repository.load(fitler = filterParam, itemsPerPage = this.itemsPerPage...)
    }
    

    在我看来,由于灵活性和副作用最小化,传递参数更可取。

    【讨论】:

    • 我没有完全理解你的想法,你的意思是我应该有一个像setRequest(Request $request) 这样的服务方法,我需要在每个方法调用上设置它,然后在我的每个方法中使用这个对象?
    • @Trent - 好吧,否则。我建议您将请求传递给每个服务方法。 Request 只是包装了一些特定的参数,因此当您从请求中添加或删除某些内容时,这不会影响您的方法签名。
    猜你喜欢
    • 1970-01-01
    • 2021-01-02
    • 2011-02-11
    • 2012-12-23
    • 2011-01-11
    • 2018-05-04
    • 1970-01-01
    • 2011-08-28
    • 2011-03-09
    相关资源
    最近更新 更多