Question

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?

Answer 1

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:

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

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 –

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

In my opinion passing through parameters is more preferable due to flexibility and side-effects minimization.