我的服务层应该是无状态的吗?
我有一个服务层,它负责处理我的控制器和域模型(即:存储库、实体等)之间的关系。
在我的服务中,我有“获取”实体的方法,例如 getArticles ,但我需要返回数组结果或对象集合。
所以我向我的方法添加了一个参数 getArticles($array = false);
(实际上我的服务不强制转换任何对象,它是由存储库完成的,但我需要向我的 API 提供该选项)
我的服务变得越来越大,我想知道在我的方法参数中定义它是否是一个好主意,我认为这是因为我认为我的服务应该是无状态的,但我想知道它是否不会最好在我的方法中有一个方法服务,它基本上执行 setUseArray($flag)
操作,并在我的服务代理它时向我的存储库提供该标志。
同样的想法,如果我使用我的服务返回分页结果,我应该在每个方法中设置页面和项目计数,还是应该在我的服务中使用全局方法来执行此操作?
有任何反馈吗?
I've a service layer which does the relation between for example my controller and my domain model (ie: repository, entities, etc..).
In my service, i've method which "get" entities, like getArticles
but I need to return either an array result or a collection of object.
So I added an argument to my method getArticles($array = false);
(Actually my service doesn't cast any object, it is done by the repository but I need to provide that option to my API)
My service is getting bigger and bigger and I'm wondering if it's a good idea to define it in my method paramater, I thought it was because I thought that my service should be stateless, but I'm wondering if it wouldn't be better to have a method in my service which basicly do setUseArray($flag)
and feed my repository with that flag when my service proxies to it.
In same idea, if I use my service to return paginated result, should I set the page and the item count in each of my method, or should I use a global method in my service to do that?
Any feedbacks?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
像往常一样,这取决于。主要取决于服务对象是否会同时使用。一般来说,使用参数传递所有内容似乎更灵活。将方法参数包装到请求实体中可以避免客户端与方法签名的紧密耦合:
我假设您有一个 Web 应用程序,并且服务对象仅存在于请求上下文中。在这种情况下,您可以安全地选择按服务对象方式设置“重复”参数。看起来也不错 -
在我看来,由于灵活性和副作用最小化,传递参数更可取。
As usual, it depends. Mostly it depends on whether service objects would be used concurrently or not. In general, passing everything using parameters seems to be more flexible. Wrapping method parameters into a
request
entity would avoid the client-side tight coupling to the method signature:I assume, you have a web application, and service object would exists only withing the request context. In that case you could safely choose making "repetitive" parameters service-object-wise. Looks not bad as well -
In my opinion passing through parameters is more preferable due to flexibility and side-effects minimization.